Re: Dar and OS X xattrs: Willing to help

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Vasilevsky wrote:
| Thanks to all who've worked on dar, it's a very nice tool.

Hello Dave,

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

This is no more true. The current development version does no more
consider two namespaces, even better, it does no more consider any
namespaces at all. The EA are just, from dar point of view, a pair of
name and value, the name is supplied by the system and stored asis with
the provided value. At restoration time things goes the same restoring
the stored name of the EA. Linux system provides names like
'system.something' or 'user.something_else', dar does not more split
theses but rather stores them like this. A set of masks let the user
define which EA has to be saved/restored, theses masks are applied to
the whole name of the EA (including namespace).

Things should now be easier to maintain and maybe more portable also.

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

This API does not covers the problem of the forks that do not exist
under Unix, does it?

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

yes, this is dangerous.

and because it would change  the
| format of slices.

That could not be the biggest problem.

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

To my point of view to cover the EA feature on MacOS X the xattr API is
the best way to have something working. Probably it should now work
without any change with the last development versions... If not it is
still possible to adapt the code, which is now very general and not much
linux specific.

For resource fork, this is much different. There is conceptually nothing
like this under Linux (OK, one could say that there is just on fork
under Unix), and so the current dar structure (software) and data
structure (archive structure) does not has place for this concept.
Depending on the available API, different different evolution of dar are
possible. If you have some pointers on the different API you think
suitable to use in dar, I could guide you to integrate this feature in
dar with the global view of dar I have which you could miss else.

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

I will consider that problem, thanks for feedback.

|

Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDNaSEpC5CI8gYGlIRApugAKCNpiav6r/XltmrcveoOh2t7bxZ9gCeNSwr
zM72W3HYQ0Rz22ba3XHtlhI=
=0etI
-----END PGP SIGNATURE-----



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php