Wayne, Thanks so much for your spot-on reply. More inline below.
On Sun, Aug 25, 2013, Wayne Davison wrote: > On Sat, Aug 24, 2013 at 3:19 PM, Daniel Freedman wrote: > > In particular, I've been having long-standing issues (just now > > getting around to trying to resolve them) when I use rsync > > with '--copy-unsafe-links' alongside the '--delete' parameter. If > > I use either of these two parameters in isolation (along with > > other shared parameters), I get the expected behavior. However, > > when I use '--copy-unsafe-links', rsync no longer properly deletes > > files that are present in the destination, but not in the source. > > Be sure to check the errors from the rsync run. I'd imagine that > one of your unsafe symlinks is bogus, and you will be getting a pair > of errors: > > symlink has no referent: "/some/path" > IO error encountered -- skipping file deletion Great call! I've definitely always been getting these errors, and they are indeed from dangling symlinks (those that don't point to valid file/dir). I had just ignored such errors, since I'm okay with my bogus symlinks not being backed up (given that there's no valid way for them to be backed up when I'm using the "--copy-unsafe-links" flag), and the errors seemed otherwise harmless (with no apparent connection to my problem hinted at in the logging)... > Because a bogus dereferenced symlink can't be replaced with a > file, it is left out of the transfer. This would cause the > receiving side to delete that missing file (symlink) in the > destination directory if deletions were allowed to > continue. Rsync currently prevents that from happening by > turning off file deletions. Hmm --- maybe it's my naivete (or lack of knowledge), but I *really* was not expecting this behavior on the part of rsync... Two questions come to mind, please: (1) Why is this the silent default? It seems (to my mind, at least) to be pretty unexpected. Let me try to break it down a bit: (a) I accept, of course, that a bogus dereferenced symlink can't be replaced with a file --- so it makes sense that it is left out of the transfer. (b) I could understand, further, that the rsync receiver would *not* want to delete the missing file (symlink) in the destination, and thus it makes sense for rsync to prevent that from happening. (c) What I don't understand, though, is why the right answer is for rsync to ignore requested deletions of *other* files / directories / etc that have nothing to do with the bogus dereferenced symlink on either the sending or the receiving side of the transfer... Instead, I would expect rsync to respect the requested deletion of these, while avoiding the deletion of items associated with the bogus dereferenced symlink. Thoughts? Regardless, I would have thought that rsync would *warn* me that my combination of these two parameters --- within a scenario where the source has a bogus symlink --- is such that the "--delete" parameter is being ignored. Don't you think it should? (Perhaps also some mention of this side-effect in the man page?) (2) How do I achieve what I "want", which is: (a) 'rsync --delete --copy-unsafe-links' should exhibit expected behavior on all files / directories / etc *NOT* associated with any bogus dereferenced symlinks on the source. (b) 'rsync' should just ignore the bogus dereferenced symlinks at the source. Might you kindly suggest which combination of parameters would achieve this? (Of course, one suggestion would be for me to delete said bogus dereferenced symlinks on the source; however, for various reasons, I really prefer not to do that, so I'm looking for other solutions.) Thanks so much for your help --- especially so in really nailing the problem I was encountering. Best, Daniel -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html