using rsync with Mac OS X

David Feldman dfeldman at
Tue Dec 18 03:40:14 EST 2001

I'm not familiar with netatalk, but along a similar line, Mac OS X 
stores resource forks and metadata differently on HFS+ and single-fork 
volumes (such as UFS or NFS). If you copy a file from an HFS+ volume 
over to a single-fork volume using the Finder it'll split the pieces 
apart and save the resource fork and metadata under variations of the 
original filename.  I don't remember the exact names but I think they're 
in the Mac OS X System Overview document...something like ._<original 

If there's a way I can help with the porting effort please let me know. 
I don't know a lot about the lower-level details, but do know C, C++, 
Cocoa, etc. and would be interested in looking at the BSD-level info you 
have on transferring OS X files.

As I stated in my earlier message, my primary interest is 
synchronization of desktop and laptop, though backup would be terrific 
too.  I'm pretty sure there are a lot of OS X users out there in need of 
both. I'm currently synchronizing with a shell script that uses ditto.


On Monday, December 17, 2001, at 11:25 AM, rsync-request at 

> From: "Chris Garrigues" <cwg-dated-55c191e81afae8e9 at>
> To: Mark Valence <kurash at>
> Cc: rsync at
> Subject: Re: using rsync with Mac OS X
> Date: Mon, 17 Dec 2001 09:17:44 -0600
> --==_Exmh_771008192P
> Content-Type: text/plain; charset=us-ascii
>> From:  Mark Valence <kurash at>
>> Date:  Sun, 16 Dec 2001 22:26:04 -0500
>> 1) convert (on the fly) all files to MacBinary before
>> comparing/sending them to the destination.  MacBinary is a well
>> documented way to package an HFS file into a single data file.  The
>> benefits with this method are compatibility with existing rsync
>> versions that are not MacBinary aware, while the drawbacks are speed,
>> maintainability, and that directory metadata is not addressed at all.
>> 2) Treat the two forks and metadata as three separate files for the
>> purposes of comparison/sending, and then reassemble them on the
>> destination.  Same drawbacks and benefits of the MacBinary route.
>> This would also take more memory (potentially three times the number
>> of files in the flist).
>> 3) Change the protocol and implementation to handle arbitrary
>> metadata and multiple forks.  This could be made sort-of compatible
>> with existing rsync's by using various tricks, but the most efficient
>> way would be to alter the protocol.  Benefits are that this would
>> make the protocol extensible.  Metadata can be "tagged" so that you
>> could add any values needed, and ignore those tags that are not
>> understood or supported.  Any number of forks could be supported,
>> which gives a step up in supporting NTFS where a file can have any
>> number of "data streams".  In fact, forks and metadata could all be
>> done in the same way in the protocol.
> A quick thought about implementation details:  It would be nice if this 
> were
> done in such a way that if I were to rsync from a non-OSX netatalk 
> system
> onto an OSX system the .AppleDouble directories would be merged back 
> into the
> files, and conversely if I were to rsync from an OSX system to a 
> netatalk
> system the resource forks would be split into .AppleDouble directories.
> I guess this would be simplest with scheme 2 above.
> Chris

More information about the rsync mailing list