Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Handle resource forks correctly with newer rsync UNIX
For rsync users, the newest version of rsync (3.0.6 as of this moment) seems to be able to handle Mac extended attributes and resource forks correctly. Unfortunately, it doesn't seem to ship with Snow Leopard, but it can be downloaded and installed fairly easily. After downloading from the above-linked site, just follow the instructions in the INSTALL text file, and remember that the make install command needs to be run with administrator privileges (sudo). Further, you may need to adjust your PATH and MANPATH settings, so that /usr/local/bin and /usr/local/share/man (the default install locations) appear earlier in the list than do /usr/bin, the home of the stock rsync.

Your current rsync scripts may need some tweaking, too. For example, the -E flag no longer refers to extended attributes (it now tells rsync to preserve executability); -X is used for extended attributes. Also, -X is not included in the standard -a (archive) flag, and should be added explicitly.

[robg adds: The version of rsync in both Leopard and Snow Leopard is quite old -- 2.6.9, which shipped in November of 2006. You can also install the newest rsync via either MacPorts or Fink.]
  • Currently 2.40 / 5
  You rated: 3 / 5 (10 votes cast)

Handle resource forks correctly with newer rsync | 8 comments | Create New Account
Click here to return to the 'Handle resource forks correctly with newer rsync' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Already in fink
Authored by: zadig on Oct 15, '09 08:44:18AM

If you are already a fink user, the current version in fink is 3.0.6-1, so you can install it that way even easier.

[ Reply to This | # ]
Handle resource forks correctly with newer rsync
Authored by: TonyT on Oct 15, '09 09:21:41AM
Please note that 3.0.6 does not properly handle the metadata for the new HFS+ filesystem compression.
Also, another problem is that the creation times are not preserved in x64 in Snow Leopard (this can be fixed at compile time.)


[ Reply to This | # ]
Handle resource forks correctly with newer rsync
Authored by: TonyT on Oct 15, '09 09:25:07AM

Also, remember to apply the fileflags.diff and crtimes.diff patches.

[ Reply to This | # ]
Handle resource forks correctly with newer rsync
Authored by: johnemac on Oct 15, '09 10:41:08AM
Bombich has instructions here

[ Reply to This | # ]
Handle resource forks correctly with newer rsync
Authored by: tedw on Oct 15, '09 11:08:40AM
I should point out that file system compression in its default form - at least if I'm reading the scattered notes I can find about it correctly - only applies to read-only system files. It is not used on user-created files, third-party applications, or other installed or created items unless a user (or developer) specifically enables it. You can find the hack to do that in this hint if you are interested. Otherwise, you should not have a problem using rsync 3.x, so long as you are careful about copying files installed by Apple (system files, Apple apps, and etc) and follow the instructions that TonyT and johnemac give above to properly compile and install 3.x on Snow Leopard..

[ Reply to This | # ]
Hint may be wrong
Authored by: SOX on Oct 15, '09 12:16:06PM

The hint is too short to judge but I believe it is supplying erroneous infromation. the built in rsync will handle forks if you use the -E option. The problem with the rsync is not a lack of fork handling but a lack of propoer change detection. if you copy large directories or copy the same thing twice with large separations in time, rsync may no properly detect that nothing changed and copy everything. THe reason for this appears to be that spotlight is changing metadat or access times.

Perhaps the hint is saying that if only meta data changed it only copies the meta data and not the whole file? that would be an improvement. but Rsync does handle forks if you use the -E option.

[ Reply to This | # ]
Hint may be wrong
Authored by: tedw on Oct 15, '09 01:08:10PM
If you like... I submitted this hint because I use rsync myself for daily backups. The default rsync 2.6.9 under 10.5.8 would mostly work well for my purposes without the -E (extended attributes) option: changed files would be backed-up correctly, though details like custom icons (and some other Finder specific attributes) would not be retained. I tried including the -E option to try and catch those attributes as well (to fix a small but irritating problem I ran across restoring a deleted file), but I found that files with resource forks would always be backed-up without regard to whether they had been changed, and the backups would have new modification dates reflecting the backup time rather than the time they were modified on the main disk. In test cases this would happen consistently, even after a few moments, not after large separations in time.

And no, I wasn't using a particularly tricky rsync setup: just rsync -aEq ... to a local storage disk.

rsync 3.x handles files with resource forks without that particular issue. If you don't care about resource forks, or don't care about modification times, then the default rsync 2.6.9 should be perfectly adequate for your needs.

[ Reply to This | # ]

Hint may be wrong
Authored by: chadvonnau on Mar 05, '13 09:40:56PM

I know this is an old thread, but I wanted to add some things for posterity.

SOX is correct that the built in rsync 2.6.9 handles extended attributes just fine with the -E option, at least on the data set that I tried it with. I synced from an NFS share (using ._ appledouble files) to a local HFS+ volume. I'm running Lion 10.7.5. I believe the issue tedw saw was legitimate, but I suspect it only happens in certain cases.

That being said, even if you're not seeing this problem, rsync 3 is worth upgrading to. It's faster, uses less memory, and is better able to fix metadata on destinations that have been prepopulated with files from a dumb copy. And if you have homebrew, it only takes a minute to install.

[ Reply to This | # ]