Overwriting symlinks on OSX

[Matt McCutchen]

On 2/24/07, David Liontooth <liontooth at cogweb.net> wrote:
> I'm trying to rsync files to a set of symlinked directories on an XServe
> running OS X.

> When I run rsync from Linux in --dry-run mode, the results are correct:

> When I do the actual run, the symlinks are overwritten and new
> directories are created; details below.
> Can I prevent this behavior and tell rsync to respect the symlinks, as
> it does in --dry-run mode?

The default is supposed to be to not "respect" existing symlinks in
the destination.  The --keep-dirlinks option makes rsync respect them.

It is a bug that rsync appears to respect the symlink on a dry run.
Rsync correctly reports that it would replace the symlink with a
directory; use --itemize-changes to see the cd+++++++.  However, when
processing files inside, it blindly follows the obsolete symlink and
concludes that the files are already there, whereas the newly created
directory would have no files on a real run.

One possible solution is to add a variable "will_unsymlink_below" to
recv_generator to hold the depth below which rsync should simply
assume destination files do not exist instead statting them through an
obsolete symlink.  However, the *_below approach is broken in the case
of --no-implied-dirs, as I mentioned in this message:
    http://lists.samba.org/archive/rsync/2007-January/017193.html

When rsync sends files inside an implied symlink "path/to/S" with
--relative, the opposite problem can occur: rsync itemizes creations
of destination files that it would find already exist if it had
actually created the symlink at "path/to/S".  This is nasty to fix.
In order to correctly process each file X under "path/to/S", rsync
needs to construct a path that goes to the same place that the path
"path/to/S/X" would if the symlink at "path/to/S" were already in
place.  Suppose the symlink's target path is "../Y".  rsync can't use
"path/to/../Y/X" if "path/to" doesn't exist yet on the destination.
And rsync can't use "path/Y/X" if "path/to" is a symlink.  There may
be additional complications I haven't thought of yet.

This is an unpleasant decision: do we want to bloat rsync with the
necessary logic to make --dry-run correct in these corner cases or
settle for a --dry-run that sometimes misleads the user?  Wayne,
what's your opinion?

Matt