change of behaviour on rsync -R and top level symlinks?

Marc MERLIN marc at merlins.org
Wed Jun 16 14:37:55 MDT 2010


On Wed, Jun 16, 2010 at 01:09:07PM -0700, Marc MERLIN wrote:
> On Wed, Jun 16, 2010 at 09:11:57AM +0200, Francis.Montagnac at sophia.inria.fr wrote:
> > 
> > On Tue, 15 Jun 2010 18:58:36 PDT Marc MERLIN wrote:
> > 
> > > The /data symlink is clobbered and replaced by a directory. Very bad!
> > 
> > > Any idea what's going on here and is there a magic flag to work around this
> > > problem?
> > 
> > I thing you simply need the --no-implied-dirs flag.
> 
> Yep, that took care of it.
> 
> Any idea why this is not default or a reason not to be using this flag all
> the time if you are used to the old version of rsync's behaviour?
 
So I read the man page more closely, it's more complicated than that.

       --no-implied-dirs
              This  option  affects  the  default  behavior  of the --relative
              option.  When it is specified, the  attributes  of  the  implied
              directories from the source names are not included in the trans-
              fer.  This means that the corresponding  path  elements  on  the
              destination  system  are  left  unchanged if they exist, and any
              missing implied directories are created with default attributes.
              This even allows these implied path elements to have big differ-
              ences, such as being a symlink to a directory on  the  receiving
              side.

This sounds all nice and good but if I have
/a/b on the source with /a -> /c  and /a -> /c on the destination,
rsync -R /a/b dest:/
should not "delete the /a symlink and make an /a directory unless I give
--no-implied-dirs" which is meant to deal with a different case but happens to help
for me here. I should keep my /a -> /c symlink on the destination without
--no-implied-dirs since I have /a -> /c on the source too, and this is what
rsync 2 did.

The man page says "This even allows these implied path elements to have big
differences, such as being a symlink to a directory on the receiving side."
except that in my case /a is a symlink to /c on both the source and
destination before the rsync starts.

It still looks like --no-implied-dirs will fix my problem while hopefully
not breaking anything else but it still looks like the change of behaviour in rsync 3
broke this pretty reasonable case.

Or am I missing something?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


More information about the rsync mailing list