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

[John Valdes]

On Tue, Aug 19, 2003 at 03:13:41AM +0000, Dave Botsch wrote:
> 
> Hopefully, the inclusion of this patch will make cfengine appeal more to
> OS X admins and then there will be more OS X people to work on cfengine
> stuff.
> 
> That's my goal with this patch.

First, let me say thanks too for putting this patch together.  I too
think it would be nice to have more OS X folks work on Cfengine,
though more selfishly, I want to use Cfengine on OS X myself, so
that's my real motivation. ;)

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

   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.  See
   
http://developer.apple.com/documentation/Carbon/Reference/File_Manager/index.html
   The MacOSX::File perl module (see http://search.cpan.org/dist/MacOSX-File/)
   uses these functions and can provide sample code.  (I was actually
   planning to add fork support to Cfengine based on their code until
   I saw your patch... :) ).

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.

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), better I think would be to use
   one of the apple standards (single or double).  This also has the
   advantage of preserving the file type and creator, since the apple
   formats store the finder info.  Perhaps the format to use could be
   specified as an option in the copy statement, 'though Cfengine
   should instead automatically figure out the format of the master.

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.
You could still add findertype= and findercreator= (or "mactype="
"maccreator=") to override what's specified in the finderinfo stored
in the file if desired.

What do you think?  I have more, but it's late...

John

-------------------------------------------------------------------------
John Valdes                        Department of Astronomy & Astrophysics
valdes@uchicago.edu                                 University of Chicago