Bug 12489 - --fuzzy --fuzzy does not work with daemon
--fuzzy --fuzzy does not work with daemon
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
All All
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2016-12-30 15:39 UTC by Ben RUBSON
Modified: 2017-01-05 21:10 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ben RUBSON 2016-12-30 15:39:14 UTC

I try to use --fuzzy --fuzzy with --link-dest :
rsync -aR -yy --link-dest="../2016-12-28/" --link-dest="../2016-12-27/" /my/folder srv::daemon/computer/2016-12-29/

But :
--fuzzy --fuzzy eligible files are not detected (--debug=FUZZY2 gives nothing at all).

Files are correctly linked, but for every file, rsync daemon logs the following :
file has vanished: "/computer/2016-12-29/2016-12-28/my/folder/file"
file has vanished: "/computer/2016-12-29/2016-12-27/my/folder/file"

I tried with the following command :
rsync -aR -yy --link-dest="/computer/2016-12-28/" --link-dest="/computer/2016-12-27/" /my/folder srv::daemon/computer/2016-12-29/

Which gives :
file has vanished: "/computer/2016-12-29/srvpath/computer/2016-12-28/my/folder/file"
file has vanished: "/computer/2016-12-29/srvpath/computer/2016-12-27/my/folder/file"

I don't have these error messages with only one --fuzzy.

I don't have the problem using a SSH server as the target instead of a Rsync daemon.

And I don't have the problem setting chroot to yes in the Rsync daemon.

So sounds like these are related to --fuzzy --fuzzy talking to a Rsync daemon with chroot=no.

Tested in several environments, with Rsync 3.1.1 and 3.1.2.

I'm also surprised that, according to these log lines, --fuzzy --fuzzy tries to reach every file in link-dest directories, even if they are absolutely not needed (simple test with destination already in-sync, or with all destination files to be simply linked (same name/date/perms etc...)).

Thank you for your support !

Best regards,

Comment 1 Ben RUBSON 2017-01-05 21:10:33 UTC
As a workaround I found a way to enable "use chroot = yes" in my production modules.
I then put the Importance of this bug report back to "normal", but keep it opened as the issue is real :)