(Intentionally top posting) For anyone that reads this thread in the future, I feel the need to correct something I mistakenly said about the way rsync works.
As opposed to what I wrote below, when rsync operates between a local and remote location, in normal operation it does not rewrite the file "in place" (with the gymnastics I mentioned below). Instead. at the destination, it creates a new file using changed segments it receives from the source (when differences exist) and uses unchanged portions from the exising copy at the destination. At the end, it "moves" the new file to the the old file (i.e., changes the name back to the original file name). There is an in place option which I expect operates more like what I described below (gymnastics to change pointers to point to new (cahnged) and old (unchanged) segments of the file). And, as (iirc) others have mentioned,, when rsync operates locally (source and destination are local) it reverts to basically a plain copy operation. On Thursday, February 26, 2026 01:27:01 PM [email protected] wrote: > But if rsync determines there are differences (by some simple means, e.g., > difference in date, size, or such) then it has to read each file, compute > some sort of checksum on "segments" of each file, compare them, and then > transmit just those changed segments. > > And then I'm not clear on how those changed segments get incorporated into > the destination file -- maybe the segments are the length of something > that is like a <darn -- what would be the right word but> the segments > "normally" on disk so that maybe it can do something like change inodes > storing the destination file to point to the changed segments? (Wish I > could think of the right words.) > > But, overall, it seems like a lot of overhead, including reading both the > source and destination file, calculating checksums, and then (partially) > rewriting the destination file. Seems worth it for a remote system, but > I'm not sure about on the same machine. And as far as disk wear, you're > reading both files and then somehow partially rewriting one with rsync, > and with cp, you're reading one file and writing one file. (Is there a > difference in disk wear between reading and writing? I guess there could > be...)
