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

[David Botsch]

We should probably come up with a todo list for this. I would propose:

1. replace in code references to ../namedfork/rsrc with the constants
from /usr/include/sys/paths.h

2. decide on what to use to specify (copy the resource fork over also)
which initially, will copy over the split data and resource forks and
later on copy over forks split into other formats as well, possibly with
formats that also include metadata.

2a. what should the split resource fork be named? Could be something like
filename-..namedfork.rsrc or just filename-rsrc or filename.rsrc (I would
prefer not to use . to prepend the file as in ._ b.c. this should not be
a hidden file)

2b. Decide what order in which to try different file types for when this
support is included

I don't think #2 will be that bad remembering what I do from the
structure of the code.

I have already slightly modified the patch file to use strn functions
instead of str functions (but have not yet applied and tested).

On Tue, 19 Aug 2003 15:32:49 -0400, John Valdes wrote:

> 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