Bug 5182 - -r --include= --exclude= broken for version>=3.0.0pre5?
Summary: -r --include= --exclude= broken for version>=3.0.0pre5?
Status: CLOSED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.0
Hardware: x86 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
: 5183 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-01-09 11:12 UTC by gabriele balducci
Modified: 2008-07-26 10:24 UTC (History)
0 users

See Also:


Attachments
Fix (442 bytes, patch)
2008-01-09 11:57 UTC, Matt McCutchen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description gabriele balducci 2008-01-09 11:12:13 UTC
Hello,

I'm probably missing something (apologies if so), but this has worked
for me for years, and starting from 3.0.0pre5 has stopped working in a
way that smells of some kind of bug.

To reproduce the (possible) bug, set up the following scene.

Remote host/directory:     remote_host:/some/dir
Local host:                current directory containing file `foo'

(I'm assuming working passwordless ssh connection between local and
remote host)



From the directory containing the file foo I issue the following command:

  rsync -e ssh  -r --include='/foo' --exclude='*' ./ remote_host:/some/dir


Now: for versions <=3.0.0pre4 this copies foo to the remote host, but
for versions >=3.0.0pre5, foo is not copied any more.

Running the command in verbose mode does not throw any light into my
(lack of) knowledge:

  rsync -e ssh  -rvv --include='/foo' --exclude='*' ./ remote_host:/some/dir

gives:

    opening connection using: ssh remote_host rsync --server -vvre30.14i .  /some/dir
    sending incremental file list
    removing duplicate name . from file list (2)
    removing duplicate name . from file list (3)
    removing duplicate name . from file list (4)
    removing duplicate name . from file list (5)
    delta-transmission enabled
    total: matches=0  hash_hits=0  false_alarms=0 data=0

    sent 51 bytes  received 15 bytes  132.00 bytes/sec
    total size is 0  speedup is 0.00


I can add that all works nicely even with version>=3.0.0pre5 the other
way around: i.e.:

  rsync -e ssh  -r --include='/foo' --exclude='*' remote_host:/some/dir ./

copies remote_host:/some/dir/foo into local current directory, as I
was always used to obtain.

Am I doing something wrong or something has changed between 3.0.0pre4
and 3.0.0pre5?

I could not find any report on this in bugzilla, and this makes me
think I might be making some gross mistake, but, as I said, that used
to work for years and still perfectly works for versions<=3.0.0pre4.

I'm on linux (2.6.23.12, i686)

I thank you very much in advance for any hint and, of course, for
making rsync available.


ciao
gabriele
Comment 1 Matt McCutchen 2008-01-09 11:24:47 UTC
I can reproduce this.  The problem happens even without the --include and --exclude options, but apparently only if the source argument is given as exactly "./".  A workaround is to change the source to ".".
Comment 2 gabriele balducci 2008-01-09 11:38:25 UTC
Ah-ah.
...and this might be related to those "removing duplicate name . from file list (2)" messages obtained in verbose mode.

Unfortunately, i've no time to dive into the sources to try to be of more use, but I'm confident that, if it's a buglett as it seems, it won't be that difficult for the maintainers to fix it

thanks again
gabriele
Comment 3 Matt McCutchen 2008-01-09 11:57:48 UTC
Created attachment 3091 [details]
Fix

The attached patch seems to fix the bug; I don't know if it's the right fix.  The trouble was that, when rsync nulled out the trailing slash of the "./" source argument, it failed to retreat the pointer at which it appended the names of files in the directory.  As a result, it tried to send ".\0/src" (i.e., ".") instead of "./src", hence the "removing duplicate name" message.  I'm not sure why this wasn't a problem in rsync 3.0.0pre4.
Comment 4 gabriele balducci 2008-01-09 12:02:22 UTC
thank you very much!
I'm going home now: I'll try the patch tomorrow and let you know

ciao
Comment 5 Wayne Davison 2008-01-09 14:09:53 UTC
This is now fixed in the latest dev version (including git and nightly tar file).

Thanks for the report and the diagnosis.
Comment 6 Wayne Davison 2008-01-09 14:10:21 UTC
*** Bug 5183 has been marked as a duplicate of this bug. ***
Comment 7 gabriele balducci 2008-01-10 02:12:17 UTC
Hello
just re-built 3.0.0pre7 with the fix and everything works fine.
Thanks a lot for the quick and efficient support

ciao