On 2/24/07, David Liontooth <[EMAIL PROTECTED]> 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 -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
