On Sun 19 Mar 2006, martin f krafft wrote: > retitle 357732 better handling of unnecessary retransmissions
As I said, the file is NOT retransmitted in the cases you show! > I understand. Will you accept this as a wishlist item? I could > imagine that rsync uses finer granularity when comparing stat > output, such that when -p/-o/-g are not passed, it doesn't compare > those parts of the stat() struct? It uses the metadata to decide whether a file is up to date or not, what other choices does it have? Besides of course always using checksums, even when the metadata is the same, but that's what --checksum is for. Hence I don't understand what you're trying to achieve. > Apart, wouldn't it make sense if rsync first ran one checksum over > the entire file, and only does the chunks if the file actually > differs? Huh? That's exactly what it does, I thought that's what I said... That's the power of rsync, the way it uses a rolling checksum to determine what parts are the same (even if they're moved inside the file!), and what parts differ. Only those blocks that are "new" are actually transmitted. Of course, rsync also offers an alternative with --whole-file, for those cases where it's faster to retransmit the whole thing instead of checksumming everything (typically useful when the IO is slower than the network). Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
