Bug 1812 - fuzzy not working in 2.6.3-pre{1,2}
fuzzy not working in 2.6.3-pre{1,2}
Product: rsync
Classification: Unclassified
Component: core
x86 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2004-09-23 03:56 UTC by Egmont Koblinger
Modified: 2005-04-01 11:22 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Egmont Koblinger 2004-09-23 03:56:04 UTC
The --fuzzy option, which I regularly use and saves me an extremely huge amount
of time and worked perfectly up to 2.6.2, doesn't work at all in 2.6.3-pre1 and

Please see bugzilla #1489 for a description of a bug in 2.6.2 which would make
it important for me to upgrade to 2.6.3.

I downloaded rsync 2.6.3-pre1 and pre2, applied g2r-basis-filename and fuzzy
patches (fuzzy says it needs the former one), ran "make proto; make" as these
patches tell me to do, and then I installed the new version.

While the old 2.6.2 version runs perfectly, the new ones seem to completely
ignore the --fuzzy option.

Here's the exact, detailed (and boring) description of what I do:

On a remote machine, created a directory 'foo' and dd'd one megabyte of
/dev/urandom to foo1.txt and then copied foo1.txt to foo2.txt.
Then I created 'foo' directory on the local machine and copied foo1.txt here.

Then I executed the following command several times:
rsync -avP --fuzzy --bwlimit=10 remotemachine:foo/ foo/
(and of course removed local foo/foo2.txt before each run of this command).

With local version 2.6.2 the command completes in 1 or 2 seconds and
successfully creates foo2.txt with the same content.

With local version 2.6.3-pre{1,2} it downloads the whole file which takes
more than 1 minute due to bwlimit. It seems it doesn't notice there is already
a file with a similar name. In these cases the access time of local foo1.txt
is not changed which means the file wasn't open by rsync.

I tried the same with all these versions of rsync running on the server, but
the server side versions seemed to be irrelevant.
Comment 1 Wayne Davison 2004-09-23 08:47:30 UTC
This was a very simple bug in the g2r-basis-filename.diff: the line that checked
if whole_file was non-zero needed to be updated to check if whole_file was
greater than 0.  I missed this in my testing because I tested local copies using
the --no-whole-file option.

So, temporary workaround: specify --no-whole-file.

Proper fix, get an updated version of the g2r-basis-filename patch (or just
manually add "> 0" to the "if (dry_run || whole_file) {" line) and all should be

I did also check in an updated version of the fuzzy.diff patch, but that was
mainly to ensure that the user can't try to specify --inplace with --fuzzy (it
also got rid of some "might be used unitialized" compiler warnings, but they
were not indicative of an actual problem, just an annoyance).

Thanks for the excellent bug report!
Comment 2 Egmont Koblinger 2004-09-23 09:45:40 UTC
Oh yes, it works now as expected. Thanks very much for this quick fix! :-)