Date: Tue, 6 Feb 2001 14:26:19 -0600
From: Dave Dykstra <[EMAIL PROTECTED]>
>From the man page:
a trailing slash on the source changes this behavior to
transfer all files from the directory src/bar on the
machine foo into the /data/tmp/. A trailing / on a source
name means "copy the contents of this directory". Without
a trailing slash it means "copy the directory". This dif-
ference becomes particularly important when using the
--delete option.
I can't help but think that perhaps we need to change the UI by, for
example, adding a switch called --copy-directory-contents, instead
of depending on whether or not there's a trailing slash there. I see
no other common Unix applications where a trailing slash makes any
difference to the semantics, and things like tcsh will often append
them when using completion whereas other tools may not. It also means
that any tool which generates pathnames for rsync command-line options
must have extra complexity to guarantee that the trailing slash either
does or does not appear, depending on what's wanted---whereas having a
normal switch would be trivial to implement, simplify the caller, and
make it far clearer to a human reading the result what is intended.
It's just too obscure. People keep getting screwed by it.
Obviously, this is an incompatible change to the existing semantics,
and will break scripts. I don't know of a clean way to deal with that.
(Have a --traditional switch as well? A --nontraditional one? [eww...])
Perhaps a good time to do this is if a --files-from= is ever added, as
part of a more general project to allow bypassing most of the weird
specialized language (via command options, trailing slashes, and so
forth) that tells rsync which files to process, in favor of letting
the user employ existing tools, with which she might be more familiar,
to pick the set. I really feel that rsync tries to do too much here.
