Thanks to all who replied! One followup question and then some questions on rsync operation (which I probably don't really need to know).
On Thursday, February 26, 2026 11:22:54 AM Greg Wooledge wrote: > On Thu, Feb 26, 2026 at 10:49:12 -0500, [email protected] wrote: ... > Assuming a one-time interactive copy, what I would normally do would be: > > cd /rhk > rsync -a . /back/rhk/ # or cp -a If I know that /rhk exists, is there anything wrong with: rsync -a /rhk /back/rhk/ # or cp -a (but I'd probably (almost certainly) do the cd && rsync as you suggest). ... > Rsync isn't just for remote copying. It still saves a bunch of time > and wear on locally mounted directories as well, since it'll skip the > content that has already been copied. I'm not 100% clear on that, maybe it depends somewhat on the size of the files with changes. Once upon a time, I read the guy that wrote rsync's thesis -- was it Andy something (embarrassing, I vaguely think the thesis might have been 185 pages but I can't remember the guy's name :-( Ahh, Andrew Tridgell. (And some of the way that the rsync command works wasn't (iirc) described in that thesis, but I may be mistaken (I'm thinking first that if a simple check determines that the file is not present on the destination it simply copies it completely), maybe some other things.) 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...) I guess a lot depends on how big the two files are and how many gymnastics the system has to go through to write just the changed portions. Far aside: once upon a time I thought there was some significant difference in the ways that cp and rsync were called, e.g., if cp -a /rhk /back/rhk worked, the equivalent command in rsync would have some difference in the way the parameters are specified. Or maybe that was a consequence of my using something like cp -a /rhk/* /back/rhk/ and is not an issue with the way Greg specifies them. (Or maybe it was a difference that got "fixed".) Oh, I'll just mention that the -u option to cp copies only changed (determined by some simple means, e.g., date, size, ?) or non-existent files (on the destination).
