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