Overwriting symlinks on OSX

[David Liontooth]

Matt McCutchen wrote:
> 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.
Thanks -- I should have seen that!
>
> 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?
To avoid bloat, consider a warning along the lines of,

   "Symlinked directories will be overwritten (use --keep-dirlinks)"

Dave