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

https://bugzilla.samba.org/show_bug.cgi?id=4080

           Summary: rsync can't find basis dirs with -n and nonexistent
                    destination
           Product: rsync
           Version: 2.6.9
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: core
        AssignedTo: wayned@samba.org
        ReportedBy: hashproduct+rsync@gmail.com
         QAContact: rsync-qa@samba.org


The man page says that relative basis directory paths are to be relative to the
destination directory.  This usually works because the receiving rsync chdirs
into the destination directory in get_local_name and then follows the paths
verbatim.

However, if --dry-run is on and the destination directory does not exist, the
receiver skips the chdir and tries to follow basis directory paths from its
original working directory, so it doesn't find the correct basis
directories.
The dry run itemizes transfers where a real run might itemize nothing, local
creations, or hard links, violating the principle that rsync should produce the
same output with and without --dry-run.

As a fix, I propose that, when --dry-run is on and the destination directory
does not exist, the receiver should chdir instead into its parent directory. 
(The parent has to exist in order for the destination to be created on a real
run, so I think it's reasonable to also expect the parent to exist on a dry
run.)  Then the receiver should remove an initial ../ from each basis directory
path that has one and discard basis directory paths that do not begin with ../

https://bugzilla.samba.org/show_bug.cgi?id=4080


wayned@samba.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #1 from wayned@samba.org  2006-10-08 16:44 MST -------
I checked-in some changes that fix this by turning relative paths in the
basis_dir[] array into absolute paths based on the destination directory when
the destination directory does not yet exist and --dry-run was used.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4080





------- Comment #2 from hashproduct+rsync@gmail.com  2006-10-08 16:47 MST
-------
Created an attachment (id=2178)
 --> (https://bugzilla.samba.org/attachment.cgi?id=2178&action=view)
Test case for this bug

Awesome!  You fixed it!  Perhaps you'd like a test case?


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4080


hashproduct+rsync@gmail.com changed:

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




------- Comment #3 from hashproduct+rsync@gmail.com  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: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=4080


wayned@samba.org changed:

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




------- Comment #4 from wayned@samba.org  2006-10-10 19:28 MST -------
I changed the function to limit the path cleanup that it will do (only allowing
a single ../ to be collapsed).

As for the itemizing of the root dir when doing a copy like this:

rsync -ai dir/ newdir/

I decided that I would like to see the "./" dir being itemized as a
new
creation, so I added code to make that happen.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.