Overwriting symlinks on OSX
hashproduct+rsync at gmail.com
Sun Feb 25 00:59:32 GMT 2007
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:
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?
More information about the rsync