1

Starting from two files

~/foo/bar1.txt
~/foo/bar2.txt

on my Mac's root volume, I copy the folder ~/foo (it's large; this is just an example) to /Volumes/Kiwi. I know from past experience that Finder is a lot faster than rsync, and so I simply use Finder for this initial copy. This creates the following files.

/Volumes/Kiwi/foo/bar1.txt
/Volumes/Kiwi/foo/bar2.txt

I would now like to keep an ongoing backup using rsync, not through Finder (since it will be incremental). (I'm aware of and use Time Machine; TM does its thing, and I would like to do my own redundant copy.)

If I edit ~/foo/bar1.txt to simulate a change (but not bar2.txt) and then run

rsync --dry-run -avz  ~/foo/  /Volumes/Kiwi/foo/

all is well. rsync indicates that only bar1.txt will be copied, not bar2.txt.

But if Finder also copied a file ~/foo/._bar3.txt, rsync will copy that file even if I have not touched it. Why?

It's not a huge deal. rsync will not repeatedly copy it, but still. The discrepancy between Finder and rsync -avz is puzzling. Am I doing something subtly foolish by starting with Finder and then switching to rsync?

Details

SSD format

The external disk is formatted using GUID partition map and APFS.

`rsync` Version

I'm using:

> rsync --version
rsync  version 2.6.9  protocol version 29

which, since I get

$ which rsync
/usr/bin/rsync

is the one that came with Ventura. Is there an alternative rsync (Homebrew, MacPorts, ..) that will behave differently?

Sam7919
  • 111

1 Answers1

3

Short answer: Don't worry about it. Those aren't actual files being copied; it's just an artifact of how Apple's version of rsync handles complex file metadata over a protocol (rsync v2) that doesn't support it natively.

Long answer: Apple's filesystems have always supported (and used) various forms of complex -- and nonstandard -- filesystem metadata. These days it's mostly "extended attributes", but in the past it's included things like type & creator codes, Finder flags, and resource forks.

When dealing with filesystems, archive formats, file transfer protocols, etc that don't support complex metadata (or sometimes even any metadata), Apple's tools tend to use the AppleDouble format, which splits the metadata into a separate file with a "._" prefix. You'll see often see these appear (if you look for invisible files) when you copy Mac files to a FAT or exFAT filesystem, archive them in tar or zip files, etc.

Apple's version of rsync uses this same method for transferring complex metadata. If you use rsync -E (or --extended-attributes), the sending process will convert the source files' metadata into AppleDouble, transfer it as a "._" pseudofile, and the receiver will decode it back into metadata and make sure the target file is set correctly.

Since this isn't an actual file, rsync's normal change detection tricks don't work, so it's just "always transferred". Also note that this even applies when the source and destination are on the same computer, because rsync runs separate sender & receiver processes even locally, and they communicate via the same protocol it'd use for a network transfer.

Finally, rsync version 3 does have support for complex metadata (provided you compile it with the right patches, and use the -X and maybe --fileflags options), but its format is different from what Apple's custom version uses (and Apple can't update to v3 for licensing reasons). So if you're transferring between a computer using Apple's version and one running rsync v3, you can get compatibility problems.

Gordon Davisson
  • 11,621