Dar and OS X xattrs: Willing to help

Dave Vasilevsky <[email protected]> Sat, 24 Sep 2005 12:01:45 -0400
Newsgroups gmane.comp.sysutils.backup.dar.general
Message-ID <[email protected]>
Thanks to all who've worked on dar, it's a very nice tool.

I've just added the current version of dar to the Fink repository of  
Mac OS X packages (http://fink.sf.net), so hopefully it will be more  
accessible to Mac users now (see note 1 at end). However, it's still  
missing support for OS X's extended attributes, including resource  
forks and ACLs.

I want to add this support, but I can't decide between the various  
implementation options available. I'll outline the issues, hopefully  
somebody will have some thoughts.


1. OS X has an existing API similar to getxattr on Linux. The  
arguments are a little different, but a bigger problem is that there  
are no standard "user." and "system." namespaces--instead it uses  
reverse-DNS type namespaces, eg: com.apple.program.attribute . Even  
worse, ACLs aren't available through the getxattr API.

So the first option is to automagically translate between "user.foo"  
on Linux and "foo" on Mac OS X. Then ACLs could be special-cased, and  
we pretend that they're really attributes of the form  
"system._apple.acl" just so we can stuff them in the slice.

2. There's a different API called 'copyfile'. It supports all EAs  
(including ACLs) very nicely, it basically creates a chunk-of-data  
representing all the EAs and stuffs it in a file. Then you can store  
this copyfile-data in an archive, and later apply the EAs in the  
copyfile-data back to a file. The standard way to deal with copyfile- 
data on a non-OS X system (or a filesystem that doesn't have xattr  
support) is to put it in a file of the form "._foo".

So the second option is to add a new member to the ea_attributs  
object to hold the copyfile-data. Then on OS X, we call copyfile() to  
apply the copyfile-data to a file--on other OSes, we just dump it  
in ._the_current_file .

This is better because it works on all filesystems on OS X and uses  
an existing standard method to deal with OS X EAs. But it's worse  
because it could overwrite a real ._file, and because it would change  
the format of slices.


So, does anybody have a preference for one of these? Or maybe a  
better idea altogether?

Dave


NOTE 1: When packaging dar, I noticed that the .mo locale files are  
used by libdar, but aren't versioned. That's not good, because a user  
could have both libdar.so.2 and libdar.so.3 installed and they will  
both want to use the same .mo file. You should probably name them  
'dar3.mo' instead of 'dar.mo'.
PGP.sig (application/pgp-signature, 186 B) - not displayed