help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark . Burgess
Subject: Re: [PATCH] OS X Resource Fork and FinderType support
Date: Tue, 19 Aug 2003 08:21:25 +0200 (MEST)


Gents,

thanks for this discussion. It seems like a good one.
I would like to see you battle it out and come to agreement
before I amek any moves to include the patch. Just remember the
important cfengine goals:

- convergence
- verifiability
- simplicity

I am not a Mac user, though I would love to try 'em out.
So let's make sure that this is done in the best possible taste.
Also, if a patch could me made against the latest sources rather
than such an old version, it would be great! (read: save Mark
lots of work)

M

On 19 Aug, John Valdes wrote:
> 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
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





reply via email to

[Prev in Thread] Current Thread [Next in Thread]