--compare-dest apparently incompatible with --checksum or --size-only

Jesse Molina jesse at opendreams.net
Sat Dec 24 22:09:38 MST 2011


The -a implication of -t was causing the problem... though I am 
struggling to think of any case where the use of -t would be desirable 
when --compare-dest is used.  Perhaps it should be simply negated with a 
warning message?

At the very least, I hope this mail will serve as a warning to others. 
I searched extensively before posting.

I verified that --size-only is now working correctly.  The fileset is 
huge and --checksum is taking awhile, but it looks like the desired 
behavior is occurring.

My modified dir is 7.0GB, the original is 6.3GB, and my new delta-backup 
is 790MB.

Thank you for your help, Kevin.

Jesse Molina wrote:
> Thanks for your reply.
> Just to be clear, when I said "delta-copy", I did not mean rsync's
> per-file delta to speed up remote transfers. I meant that I am basically
> making an incremental backup of the directories in question.
> I have a base-install dir (fresh set of files), a modified-install dir
> (some files modified, some deleted, some added), and the output, which
> should only include files changed or added in modified-install compared
> with base-install.
> My use of -a is out of habit. Thanks for the tip. I will look into it's
> use in more detail. However, what you are describing is basically what
> --copy-dest does, instead of --compare-dest. My opinion is that the
> behavior which --compare-dest implies as desirable to the user would
> logically override and negate anything which would cause the same file
> to appear in the "delta-backup" output dir which was in the "original"
> dir below.
> I suspect there is some tool out there which does exactly what I am
> trying to do, of which I am currently ignorant of, but I may have to end
> up writing a script which will hash the files to figure out what to
> copy, or use fdupes after a full copy to eliminate the copies produced.
> Kevin Korb wrote:
>> Hash: SHA1
>> If you use -a then rsync will fix the time stamps if they are
>> different. Therefore rsync will have to copy them to fix the time
>> stamps. If you don't care about timestamps then don't tell rsync to
>> sync them.
>> Your source and target are both local paths. That means that rsync is
>> running with --whole-file forced. It will not do a delta transfer
>> anyways.
>> On 12/24/11 22:21, Jesse Molina wrote:
>>> I am working with rsync on Debian, package version 3.0.9-1.
>>> I am trying to use rsync --compare-dest to make a delta-copy of a
>>> directory.
>>> In my case, the mtimes are all unreliable. The data is the same,
>>> but the times are all messed up and always will be.
>>> I am trying to use --compare-dest with --checksum or --size-only
>>> and it does not work. All files are transferred and the delta copy
>>> output is the same size as the local compared directory.
>>> I would rather not use --size-only for obvious reasons (eh, 1, 0,
>>> what's the difference?)
>>> Example:
>>> rsync -v -a --checksum --compare-dest=/original /modified
>>> delta-backup
>>> I could use fdupes to build a list instead, but it would be nice
>>> if rsync would would.
>>> Please correct me, document if this is true, or fix it.
>>> Other ideas?
>> - --
>> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
>> Kevin Korb Phone: (407) 252-6853
>> Systems Administrator Internet:
>> FutureQuest, Inc. Kevin at FutureQuest.net (work)
>> Orlando, Florida kmk at sanitarium.net (personal)
>> Web page: http://www.sanitarium.net/
>> PGP public key available on web site.
>> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
>> Version: GnuPG v2.0.17 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> we4AoNp5oBZge+QOPvROlwKWeCjy451X
>> =xhID
>> -----END PGP SIGNATURE-----

# Jesse Molina
# Mail = jesse at opendreams.net
# Page = page-jesse at opendreams.net
# Cell = 1.602.323.7608
# Web  = http://www.opendreams.net/jesse/

More information about the rsync mailing list