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

[Phil Howard]

On Fri, Nov 30, 2001 at 07:42:17AM -0700, tim.conway at philips.com wrote:

| from "man rsync":
|      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  differ-
|      ence  becomes particularly important when using the --delete
|      option.
| Wonderful things, those manuals.  Warning:  in my experience, this gives 
| unpredictable results.  it does NOT, in fact, always detect all the 
| content of the directory, and as a result, a --delete can have 
| catastrophic consequences.  I have not had time to try to figure out why 
| this happens, but my few tests aren't even repeatable... if there are more 
| than maybe 10 entries in the directory, something is always left out, but 
| rarely the same thing twice.  Needless to say, I never use that syntax.

If the source is a file and the destination is a file, or non-existant,
then you get a straight replication.  However, if the destination is a
directory, it puts the file _into_ the directory.  And this happens even
if the source is a directory (i.e. the source directory goes _into the
destination directory).  This is classic UNIX behaviour, and from that I
presume "correct" for rsync.  However, this behaviour (be it in rsync or
anywhere else, such as cp) is a big pitfall.  On a local machine, it's
easy enough to test the target before executing the command.  On a remote
it's somewhat more cumbersome.

I have found that for rsync, when I want to replicate a directory from one
machine to another and want to be certain that I am not putting one into
the other, but instead making one "become" another (e.g. treated as peers)
that the syntax of putting "/." at the end of both source and destination
does the trick.  Whatever is _in_ the source goes _into_ the destination.
does require the destination must exist in advance, else the reference to
"/." in the destination will fail (and thus so will the transfer).  But at
least I can do ssh to make the directory first (which might fail if the
destination is already a file, but I don't have to worry about getting a
reliable status from ssh concerning that because rsync will subsequently
fail in that case, too).  The end result is I get expected results or I
get a failure, but I don't get unexpected results (like filling up a disk
because files went in the wrong place, or deleting unintended files).

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
it, so maybe I encountered that problem.  But "/." on the end works for me
and is what I have been using in all my backup scripts.

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