<LJ-CUT text=" --More--(13%) ">
- Do nothing different than what I did before, and back up my Mac to a remote Linux machine. This means my backups won't have resource forks saved. What will break if I later restore those? Probably nothing?
Use the /usr/bin/rsync (2.6.3 proto 28) shipped by Apple with 10.4. In this version, the "-E" argument causes rsync to preserve resource forks, but:
- it seems to always considers them to be "changed" (that is, with -v it will print a line for every file that has a resource fork, even if there haven't been any changes, which is annoying);
it only works when the target file system is HFS: if you point it at a remote Linux box, you get a protocol version mismatch error. (Solved by backing up to a Firewire HFS drive instead of to a Linux server, I guess, but that'd be a waste as I have plenty of room on the disk in the Linux box...)
RsyncX: again, this version only works with HFS on both sides. I can't see a reason to use this in preference to the one that Apple ships.
Patched rsync+hfsmode: this can back up resource forks to remote non-HFS servers, but when going the other direction, does not re-assemble the magic dot-files back into resources. This sounds generally to be the most sensible solution of the three, but my instincts tell me, "the fact that there is no .dmg binary distribution of it means that only 5 people in the world are actually using it, and you don't want to be one of those."
Update: In case you were curious, I'm going with option #1, "ignore the problem".