change of behaviour on rsync -R and top level symlinks?
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.
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
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?
"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