Bug 9657 - --compare-dest results inconsistent between major 2 and major 3
Summary: --compare-dest results inconsistent between major 2 and major 3
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.9
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2013-02-13 08:01 UTC by smapjb
Modified: 2013-05-27 00:05 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description smapjb 2013-02-13 08:01:44 UTC

I use the compare dest option to calculate a residual difference directory of files.. this has been very successful.

I noticed when running on a box with version 3.0.9 of rsync that this feature was giving me different results to before.

Re-created on my Mac thus:

Note: The compare-dest test passed for both builds

phillyair:rsync philipc$ ls
rsync-2.6.9	rsync-3.0.9
phillyair:rsync philipc$ mkdir -p compare/src1 compare/src2
phillyair:rsync philipc$ cd compare/
phillyair:compare philipc$ touch src1/file1 src1/file2
phillyair:compare philipc$ touch src2/file1 src2/file2 src2/file3
phillyair:compare philipc$ ../rsync-2.6.9/rsync -av --size-only --compare-dest=../src1/ ./src2/ dest1
building file list ... done
created directory dest1

sent 165 bytes  received 60 bytes  450.00 bytes/sec
total size is 0  speedup is 0.00

phillyair:compare philipc$ rm -fr dest1
phillyair:compare philipc$ ../rsync-3.0.9/rsync -av --size-only --compare-dest=../src1/ ./src2/ dest1
sending incremental file list
created directory dest1

sent 118 bytes  received 40 bytes  316.00 bytes/sec
total size is 0  speedup is 0.00

I would expect just the difference to be in the dest directory as is the case for rsync-2.6.9.
Comment 1 Wayne Davison 2013-05-27 00:05:54 UTC
There have been a lot of bug fixes in compare dest over time, including proper determination of files not really being equal due to things like permission differences, xattr differences, etc.  (All depending on what you tell rsync to preserve.)  I'd imagine this is one of the instances that earlier rsyncs got wrong.  e.g., in your test case, you'd need to specify --no-t if you don't want a different mtime to cause the files to be unequal.