Help debugging an issue with --fuzzy --fuzzy and --link-dest

Andrew Gideon c182driver1 at gideon.org
Thu Mar 22 08:23:13 MDT 2012


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


More information about the rsync mailing list