using rsync with Mac OS X
dfeldman at designtheworld.com
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 lists.samba.org
> From: "Chris Garrigues" <cwg-dated-55c191e81afae8e9 at deepeddy.com>
> To: Mark Valence <kurash at sassafras.com>
> Cc: rsync at lists.samba.org
> Subject: Re: using rsync with Mac OS X
> Date: Mon, 17 Dec 2001 09:17:44 -0600
> Content-Type: text/plain; charset=us-ascii
>> From: Mark Valence <kurash at sassafras.com>
>> 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
> done in such a way that if I were to rsync from a non-OSX netatalk
> 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
> system the resource forks would be split into .AppleDouble directories.
> I guess this would be simplest with scheme 2 above.
More information about the rsync