DO NOT REPLY [Bug 4080] rsync can't find basis dirs with -n and nonexistent destination

samba-bugs at samba-bugs at
Mon Oct 9 22:47:59 GMT 2006

hashproduct+rsync at changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

------- Comment #3 from hashproduct+rsync at  2006-10-09 17:47 MST -------
This isn't completely fixed.  fix_basis_dirs calls clean_fname, which will
remove all x/../ sequences from each joined basis dir path, not just the one
straddling the boundary between destination path and original basis dir path. 
This might not be correct if x is a symlink.  For example:

$ mkdir zone
$ ln -s . zone/me
$ mkdir src basis
$ touch src/foo
$ rsync -a src/ basis/
$ rsync -n -ai --compare-dest=../../basis/ src/ zone/me/dest/
cd+++++++ ./
>f+++++++ foo
$ rsync -ai --compare-dest=../../basis/ src/ zone/me/dest/
.d..t.... ./

I doubt that a correctly written command line will ever produce incorrect
results due to this bug.  However, what could happen is that a user writes
"../" steps in the basis dir path expecting them to cancel steps in the
destination path, not realizing that some of the steps in the destination path
are symlinks.  The user wisely runs rsync in --dry-run mode first and rsync
seems to find the basis dir correctly, so she assumes her command is correct
and runs rsync for real--and rsync doesn't find the basis dir.

Another question: why does rsync itemize the top-level destination directory as
a creation in --dry-run mode but not in real mode?  Maybe this should be a
separate bug.

Configure bugmail:
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the rsync mailing list