>While potentially a useful option, you wouldn't want the protocol to >automatically always check for it, since it would preclude rsync on
This extension need not break any existing mechanism; if the hash of the receiver's copy of the file doesn't match the start of the sender's file, the protocol would continue as before. >So at best, you'd only want to enable this option if the only thing >for the entire set of files in a given run were files known to expand >this way. That's certainly reasonable, as you probably know when you issue an rsync command whether the file in question generally changes by simple appending. (I.e., I'd specify the option whenever I transfer a log file or mailbox). The main drawback I can see to exchanging hashes by default is the extra receiver CPU time consumed in producing them. >Alternatively, even with rsync the way it is today, what I do is >manually bump up the blocksize to something large (say 16 or 32K). This sounds like an excellent idea, and I'll give it a try. As the blocksize reaches the receiver's file size, the scheme essentially approaches my idea. Phil