Re: [PATCH] OS X Resource Fork and FinderType support

[John Valdes]

On Tue, Aug 19, 2003 at 10:44:30AM -0400, David Botsch wrote:
> 
> But, it is documented on Apple's Developer Connection web site. Also
> defined in /usr/include/sys/paths.h

I missed those; I had originally read about the /rsrc trick in a
USENIX 2000 paper (http://www.mit.edu/people/wsanchez/papers/USENIX_2000/) 
which referred to the old path, but learned the new path (..namedfork/rsrc) 
by running "strings" on /mach_kernel. :)

> We've said OS X all along, but in reality, this needs to work properly on
> Darwin, I think... is Carbon available on Darwin? Or, maybe we don't care
> for actual Darwin?

That's a good point.  Personally, I'm only interested in OS X, but if
we could generalize to just Darwin, then I think we should.  I don't
know for sure, but I would guess that Carbon's not available for
Darwin, which means we probably shouldn't use the Carbon APIs.  Anyone
know if Apple's implemented any system calls that allow access to
forks?  I looked for a little, but couldn't find anything.  If not,
then since ../namedfork/rsrc is #define'd in paths.h, I have no
objection to using that in the Cfengine code.  Using that will indeed
be simpler than the Carbon APIs, as you say.

> So, someone needs to decide how to modify the copy statement to
> say, also include the resource fork.

I need to think about this more (and look at the code... :) ).

> > 3) I don't like the idea of storing the raw data & resource forks for
> >    the master.  There are already too many Mac file formats in use:
> >    binhex, macbinary, applesingle & appledouble; this is yet another.
> >    While admittedly this is the easiest one to generate (as long as
> >    ..namedfork/rsrc continues to work), 
> 
> Ease is a very good thing.
> 
> Perhaps starting with this and then adding support for other split the
> fork format types... volunteers?

That would be agreeable.  I can lend a hand with this.

John