Why does one of there work and the other doesn't

Phil Howard phil-rsync at ipal.net
Tue Dec 4 03:16:52 EST 2001


On Sun, Dec 02, 2001 at 09:31:25PM -0500, Mark Eichin wrote:

| > Perhaps a trailing "/" instead of training "/." is supposed to work.  I do
| > not remember why I didn't start using it, but I am sure I would have tried
| 
| Quite possibly because you've been bitten by class cp/rcp; cp is not
| idempotent, in that if you "cp -r foo bar" where foo is a dir and bar
| doesn't exist, you end up with a bar that has the contents of foo
| (ie. foo/zot -> bar/zot) and if you do it twice, cp sees that bar is a
| dir and inserts it instead (so foo->bar/foo, foo/zot->bar/foo/zot.)
| TO make it worse, on BSD-ish systems, traditionally adding a trailing
| slash makes it treat bar as a directory (bar/ == bar/"" == bar/.), but
| under sysv-ish systems it doesn't change the interpretation (bar/ ==
| bar, even if bar doesn't exist.)
| 
| Partially *because* of this horror, rsync is (and is documented to be)
| consistent, and to have an explicit interpretation of trailing slash
| (that is consistent with bar/ == bar/. as far as destinations are
| concerned)  and is independent of the existence of the destination, so
| you can expect it to do the same thing when run twice.  This is one
| reason i'll often run rsync -a on local files rather than cp -r...

I have certainly been bitten by that, and it is not limited to cp and rcp,
either.  Another example I know that has bitten with disasterous effects
is the "ln -s" command.  If the destination does not exist, it puts a symlink
there.  If the destination exists and is (even if "is" means a symlink that
points to) a directory, it puts the new symlink in the directory named.
So doing "ln -s" twice with a directory target can produce two different
symlinks.  Even hard links have a problem with target directories, although
the "twice" issue is not relevant since you can't hard link a directory
itself (if your system is not broken, unlink pre-ptx Dynix way back in time).
On some systems the "-n" option gets around this on "ln -s".

I'll do some tests with training "/" instead of "/." to see if that works
for me now with 2.5.0.  It may have been a bug in an older version.  If I
get any unexpected results with 2.5.0 I'll report back with those.

Consistency is a great value.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------




More information about the rsync mailing list