[Bug 13735] Synchronize files when the sending side has newer change times while modification times and sizes are identical on both sides

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=13735

Wayne Davison <wayne at opencoder.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Wayne Davison <wayne at opencoder.net> ---
Yes, the quick-check algorithm relies on the user and the apps to not make a
data change and then back-date the mtime to lie about when the file was last
modified. To help deal with this hiding of changes, the rsync patches repo has
several checksum-caching idioms that accelerate a --checksum transfer. My
favorite is db.diff that allows you to stash off checksum info in a local
SQLite db file (or even a shared Mysql db).  Such a setup doesn't avoid all
redundant checksum computations (since the ctime can change on a file that has
no data changes), but it does make checksum transfers MUCH faster.

As Kevin mentions, the --checksum algorithm could also be improved to make it
more selective, but that would require a protocol change and (in the simplest
generator modification) we'd need to make the generator sit around and wait for
its requested checksum data for each file that needs it before finishing up the
current file and moving on to check the next one. Such a revised checksum
method would be required for any maybe-checksum processing, such as the options
you propose. Your options would also require adding in ctime info into the file
lists. One nice thing about the checksum-caching patches is that you can make
use of the optimization on just one side of the transfer and the other side
gets the normal checksum-using file data.  It also allows the sharing of
updated checksum info between multiple rsync copies (whereas your suggested
options would require each source/destination ctime difference to re-compute
the checksum).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.