rsync - Mar 2012 - Help debugging an issue with --fuzzy --fuzzy and --link-dest

I've identified a situation where the combination of --fuzzy --fuzzy 
(yes: two of them) and --link-dest is not behaving as I'd expect.  I'm 
first wondering if my expectation is wrong.  Assuming that it is not, 
then I'm wondering how best to figure out the problem.

The double use of --fuzzy is based upon https://bugzilla.samba.org/
show_bug.cgi?id=4056 which should be present on both sides of the 
transfer since one is running 3.0.7 and the other 3.0.3.

What I'm copying is a /var/log/apache2 directory build w/o logrotate's 
"dateext" option.  So on day N a given log file might be named 
error_log.2.gz while on day N+1 that same file will be named 
error_log.3.gz.

I am using --link-dest is a dirvish-like way to build complete snapshots 
while only moving changes.  I have tested this with --compare-dest as 
well.

The issue is a simple one.  I expect (using the example file names above) 
the inode number for error_log.2.gz in the snapshot for day N to be the 
same as the inode number for error_log.3.gz in the next day's snapshot.  
That is not occurring.  

Is my expectation correct?  I'm wondering, for example, if the presence 
of a different file named error_log.3.gz in the day N snapshot is 
preventing --fuzzy from having any effect.  That is, if there is a 
potential basis file based upon the name match, does the fuzzy match not 
occur even if that potential basis file is not a match?

I'm wondering about this because of a phrase in the part of the rsync man 
page describing the fuzzy option: "This  option tells rsync that it 
should look for a basis file for any destination file that is missing."  
In this case the "by name" basis file exists, but is not a match. 
Will
the --fuzzy option not have an effect in this case?

Assuming my expectation is correct, and that --fuzzy should have an 
effect in this case, I'm wondering how best to test what's occurring.  
I've tried using --itemize-changes in a --dry-run, but all it
tells me is ">f.st......" which is what I'd expect if the
proper basis
file weren't found.  But it isn't helping me understand why it isn't
found.

Any suggestions in how to examine this?

Assuming my expectation above is incorrect, and that --fuzzy is 
effectively ignored if there is a file of the same name but which is not 
a match, is there a way around this?  That is, is there some extra option 
which forces the fuzzy comparison when the identified possible basis file 
is not a match?

Thanks...

	Andrew

On Thu, 22 Mar 2012 14:23:13 +0000, Andrew Gideon wrote:
> Assuming my expectation is correct, and that --fuzzy should have an
> effect in this case, I'm wondering how best to test what's
occurring.
> I've tried using --itemize-changes in a --dry-run, but all it tells me
> is ">f.st......" which is what I'd expect if the proper
basis file
> weren't found.  But it isn't helping me understand why it isn't
found.
I thought to try renaming one of the files on the destination.  I changed 
"ads_live_access.log" to "HOLD.ads_live_error.log.9.gz".

This had the effect of changing:

	f.st...... ads_live_error.log.9.gz

to

	f+++++++++  ads_live_error.log.9.gz

If I am interpreting this correctly, then even with the lack of a file 
named ads_live_error.log.9.gz on the destination side, no "fuzzy" file
is
being sought (or at least found).  Instead, ads_live_error.log.9.gz is 
simply to be (re)copied.

Note that the source ads_live_error.log.9.gz would not match the 
destination "HOLD.ads_live_error.log.9.gz".  Instead, it should have 
matched the destination ads_live_error.log.10.gz.  I mention this in case 
that plays a role in this "failure".

Thanks...Andrew