Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

[Daniel Freedman]

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