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


Click here to return to the 'Hint may be wrong' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
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 | # ]