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

[Dave Botsch]

Let me rebuttal just a bit..

Simply saying metadata= isn't good enough, as meta data includes finder
type codes and finder creator codes (and probably other stuff that we
don't care about here), so for this the patch is using "findertype=XXXX" -
frankly, Mac admins are more likely to be familiar with the concept of
Finder Type codes than with the concept of Metadata, from what I've seen
over the years.

I thought about adding findercreator=XXXX as well, but didn't really need
it so didn't do it.

Also understand that metadata isn't a fork. It's just that, file system
metadata. Other OSes have metadata in their filesystems, but not type and
creator codes.

Saying something like fork=rsrc is a neat idea. Would need to default to
data fork if fork=not present, otherwise, would break doing stuff on other
OSes when config files specify common things on both OSes. Regardless,
would still need to filter for ..namedfork. It's an Apple thing :/

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.



On Mon, 18 Aug 2003 22:39:30 -0400, Daniel Pittman wrote:

> On Tue, 19 Aug 2003, Dave Botsch wrote:
>> On Mon, 18 Aug 2003 17:55:10 -0400, David Douthitt wrote:
>> 
>>> The version of rsync on MacOS X is rsync 2.4.6 enhanced for OS X by
>>> Kevin A. Boyd. In fact, using this version of rsync causes problems
>>> when used with standard UNIX hosts as it complains of missing files...
>>> forks, presumably.
>> 
>> Yep.. I would guess that rsync is looking for the ._filename which is
>> the resource fork combined with the metadata.
>> 
>> With the cfengine patch, we only look for resource forks and metadata
>> if the config file says to look for them. So, "enhacned" cfengine can
>> run normally as long as there is not a directory named "..namedfork" in
>> the config file copy section.
> 
> Bleh. How about a 'metadata=...' option to the standard copy, indicating
> that this is to update the metadata fork, or a 'fork=[meta|data|...]'
> option to specify which fork to update with this copy operation?
> 
> Magic pathnames are ... suboptimal, in my experience.
> 
>        Daniel
 

-- 
********************************
David William Botsch
dwb7@cornell.edu
********************************