change of behaviour on rsync -R and top level symlinks?
marc at merlins.org
Sat Jun 19 12:01:00 MDT 2010
On Fri, Jun 18, 2010 at 10:44:45PM -0700, Wayne Davison wrote:
> On Wed, Jun 16, 2010 at 1:37 PM, Marc MERLIN <marc at merlins.org> wrote:
> > 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.
> See the --relative option in the man page:
> Beginning with rsync 3.0.0, rsync always sends these implied directories as
> real directories in the file list, even if a path element is really a
> symlink on the sending side. This prevents some really unexpected behaviors
> when copying the full path of a file that you didn???t realize had a symlink
> in its path. If you want to duplicate a server-side symlink, include both
> the symlink via its path, and referent directory via its real path. If
> you???re dealing with an older rsync on the sending side, you may need to use
> the --no-implied-dirs option.
> So, in your case, you're wanting to both duplicate the /a symlink, and
> something down in the /c heirarchy, so you could copy both /a (the symlink)
> and /c/b (the real hierarchy) in the same transfer. Or just use --no-i-d,
> as you discovered.
Ok, thanks for the info.
Now, from someone who was using rsync 2.x, is it safe to always have
--no-i-d with --relative in rsync 3 if you expect the same exact behaviour
you used to have with rsync 2?
(We already established that --no-i-d does restore the rsync 2.x behaviour
in the case I gave, but we're a bit nervous that it could also introduce
extra behaviour in other cases that we didn't think about, and that would be
"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