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
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
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)
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
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 (18.104.22.168, i686)
I thank you very much in advance for any hint and, of course, for
making rsync available.
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 ".".
...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
Created attachment 3091 [details]
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.
thank you very much!
I'm going home now: I'll try the patch tomorrow and let you know
This is now fixed in the latest dev version (including git and nightly tar file).
Thanks for the report and the diagnosis.
*** Bug 5183 has been marked as a duplicate of this bug. ***
just re-built 3.0.0pre7 with the fix and everything works fine.
Thanks a lot for the quick and efficient support