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

[David Botsch]

On Tue, 19 Aug 2003 01:11:40 -0400, John Valdes wrote:

> more selfishly, I want to use Cfengine on OS X myself, so that's my real
> motivation. ;)
> 

Yes. It was selfishness on my part as well :)

> That said, there are a few issues I have about the approach you took
> with your patch:
> 
> 1) I don't think it's a good idea to reference the resource fork
>    directly using the ..namefork/rsrc path, as this is unsupported by
>    Apple and so subject to change at anytime (I think this path was
>    different in one of the early OS X beta's).  Instead, it would
>    probably be better to use supported (and documented ;) ) function
>    calls to access the forks.  As Daniel says, magic pathnames are
>    suboptimal...
> 

My previous understanding was that the ..namedfork/rsrc was
supported while the shortcut of filename/rsrc was unsupported and
actually marked to go away. Granted, this doesn't work for UFS
filesystems, but the intention was only to take care of HFS+ filesystems.
Maybe UFS will be worth thinking about in Panther, but not at the moment.

But, it is documented on Apple's Developer Connection web site. Also
defined in /usr/include/sys/paths.h (though, I'm not using the constants
there and probably should, such that a change to the specifiers wouldn't
break the code).

>    I don't know what Apple recommends for Darwin apps, but ditto and the
>    CpMac/MvMac utilities appear to use the Carbon File Manager
>    functions.  
> 

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?

Another reason I used fork specs was that only docs I could find on the
Carbon API at the time were a total mess. Fork specs were simple and
clean.

> 2) I don't like the idea of having two copy: statements for one file
>    copy, one statement for each fork.  That seems to go against the
>    Cfegine philosophy (where you just tell Cfengine what you want, and
>    it takes care of figuring out all the details, like determining if it
>    needs to copy both a data & resource fork).  More practically,
>    requiring two copy statements per file can be error prone (if you
>    list them in the wrong order or give inconsistent attributes in the
>    two statements), and it means that you double the number of lines in
>    your config files for file copies.  Esthetically, it clutters the
>    config files with redundant information.
> 

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


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

> 
> I haven't given this sufficient thought yet, but perhaps we could have a
> "format=mac" option (or whatever) which triggers all the fork logic.

Good idea.