Bug 5647 - A search through the --compare-dest dirs should stop at the first present file
Summary: A search through the --compare-dest dirs should stop at the first present file
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All All
: P3 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2008-07-29 14:37 UTC by Matt McCutchen
Modified: 2008-11-19 04:22 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 Matt McCutchen 2008-07-29 14:37:38 UTC
Suppose I have a series of sparse incremental backups and I want to make a new backup, specifying all the previous ones as --compare-dest dirs.  Any source file that differs from its last recorded state in the backup series should be copied to the destination.  However, in the current --compare-dest implementation, the file is only copied if it differs from *all* recorded states.  Thus, if the file is changed and then reverted, the reversion won't be represented in the backup series.

To fix this, we need a way to make --compare-dest dirs specified earlier on the command line hide later ones.  Then the correct result is obtained by listing the previous backups in order from newest to oldest.  Wayne suggested a while ago that this new behavior should become the default:


I'm not so sure because I have a use case for the current behavior.  In reviewing obsolete versions of my Web site for content that I might want to keep, I had several trees with some differences among them.  I wanted to identify files in one tree that were not matched in any of the other trees and copy them to a new tree for review, so I used multiple --compare-dest dirs and relied on rsync to omit files matched in any of the dirs.  Wayne, if this use case isn't important enough, please feel free to change this report from an enhancement to a bug and change the default behavior.
Comment 1 Wayne Davison 2008-08-01 21:34:45 UTC
I think the current behavior is broken for the most useful use of multiple --compare-dest directories.

For your alternative use-case, a less easy way to do the same thing would be to specify --link-dest and check to see which files ended up with no hard links.