Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???
freedman at systems.cs.cornell.edu
Thu Sep 5 19:46:40 CEST 2013
Any additional thoughts from those on the list (or other rsync devs)
regarding issue / question below? Guidance would be much appreciated!
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
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
(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.
More information about the rsync