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 pre2. 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.
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 well. 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!
Oh yes, it works now as expected. Thanks very much for this quick fix! :-)