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

Marc MERLIN marc at
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> 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:  

More information about the rsync mailing list