using rsync with Mac OS X

[Mark Valence]

So, that's one vote each for options 1, 2, and 3 ;-)

I agree that the ideal implementation would support HFS+ as well as 
netatalk's .AppleDouble scheme, Mac OS X's ._<filename> scheme, and 
MacBinary for all the rest.  This can certainly be a goal of the 
implementation, but personally I am interested in the HFS+ on Mac OS 
X part of the problem.

My implementation, whether it is MacBinary based or a change the the 
protocol, will leave room for these alternative schemes.  Right now, 
I am thinking that MacBinary is the way to go.  This doesn't give the 
flexibility and extensibility that a protocol change would give, but 
it does have the benefit of supporting existing rsync versions.

Chris I., I'm not sure what you mean by "done at the Darwin level". 
If you mean that it should be done based on Darwin/BSD APIs and not 
Carbon/Cocoa APIs, then I am in full agreement with you.  The calls 
that I'd use to access the resource fork are posix calls 
(essentially, it's just an open() call), although the calls to get 
HFS metadata are Mac OS X-specific (but not Carbon calls).

Anyway, I'm still mulling all this over, so any suggestions are more 
than welcome.  Once a path is chosen and code is written, things will 
be harder to change ;-)

Regards,

Mark.


Chris Garrigues wrote:

>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.


David Feldman wrote:

>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 filename>.
>
>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.


Chris Irvine wrote:

>I would lean toward option "1" for several reasons. Primarily it 
>could probably inter-operate safely with non-HFS or older versions.
>
>How about a flag that changes the mode to detect named forks and 
>encode them in-line. These encoded files could be safely synced to 
>non-forked storage destinations or tape. A simple tag passed at the 
>beginning of a session could notify the destination that MacBinary 
>decoding could be attempted if available.
>
>I also understand the need for named resource files for systems like 
>netatalk. The problem with this is that every named fork system is 
>different: netatalk, Xinet, Helios, OSX Finder. This is a lot to 
>chew. I would rather the user post process files to get them into 
>the named fork method if they must. If you are going between two 
>systems using the named fork technique, this whole process is 
>unneeded.
>
>Option "3" might be the best. It seems to me that this could end up 
>requiring a lot of changes to the protocol.
>
>It should also be noted, that a project like this should be done at 
>the Darwin level. There have also been discussions on the 
>darwin-development list in June 01. No one really stared anything, 
>however they did discuss at length how access to resource forks 
>might be done while stying inside posix calls.