rsync - Jun 2005 - Behavior of --checksum, suggestion

Hi rsync folks,

I understand that by default, rsync will re-copy a file if the
timestamp differs, but the size is the same.

Sometimes, though, I have large files whose mtime have been changed
but are otherwise identical.  It seems a solution to this is
--checksum, but it seems like --checksum computes the checksum for ALL
files, which is time consuming.

What would be nice is if we could have a --checksum=ifneeded, which
would compute the checksum of two files only when their size is the
same but the mtime differs.  If the files turned out to have the same
checksum, the destination's mtime would simply be updated without the
whole file being re-transferred.

Is this something that would be hard to implement?

Thanks,
Moshe

-- 
Moshe Jacobson -- http://runslinux.net -- AIM: Jehsom
| This message is strictly confidential; it should be shown to nobody |
| except the listed addressee(s). If you've received this message in  |
| error, please promptly delete it and notify the sender.             |

On Tue, Jun 07, 2005 at 04:46:43PM -0400, Moshe Jacobson
wrote:
> Is this something that would be hard to implement?
Yes, it would be rather awkward in the current protocol.  The way things
currently work, the receiving side needs to have all relevant info
already available in order to decide what files to send.  One possible
solution would be to add an extra "phase" prior to the file-transfer
phase (before the receiving side forks) where the receiver makes a pass
through the files and requests checksums for files that might need to be
transferred, and then proceeds on to the normal checksum-sending phase
(after forking) but with an optimization that allows it to avoid calling
stat() on all the files all over again (it would flag changed files,
required dirs, etc. during the earlier checksum phase).

So, that would be quite a big change, which probably means that it won't
happen -- at least, not in the current rsync (hopefully a future,
improved-protocol rsync will be more flexible in this regard, and it
would sure be nice to get around to working on it again before too
long).

..wayne..