Re: Re: Error reading EA

Wesley Leggette <lists-+42/j/[email protected]> Mon, 21 Mar 2005 22:45:25 +0100
Newsgroups gmane.comp.sysutils.backup.dar.libdar
Message-ID <1111441525.3135.22.camel@localhost>
On Mon, 2005-03-21 at 21:20 +0100, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Johnathan Burchill wrote:
> | Hi Denis,
> 
> Hello Johnathan,
> 
> |
> | From the dar-support list archive, message of 2005-03-01 12:30:
> |
> |
> |>| They explictly mention the security namespace but I don"t know at all
> |>| if this is standard.
> |
> |
> |
> |>I don"t know neither. I will look at this soon.
> |
> |
> | On my Slackware 10.1 box, "man 5 attr" shows 4 namespaces:
> |
> |        "Currently the security, system, trusted, and user extended
> |        attribute  classes  are  defined as described below. Addi-
> |        tional classes may be added in the future."
> |
> | The fact that more may be added in future makes me think there must be
> a way
> | to implement EA support in libdar in a more general way, that is
> independent
> | of specific namespaces...
> |
> 
> Yes, this is the object of a request for evolution, and of course I
> don't want to have to change dar upon each new namespace that could
> appear in the future. Historically (may 2002) when I read the
> documentation provided by Andreas Gruenbacher (Author of EA/ACL) only
> two namespaces were defined and it seemed there were no need to have
> some more... :-)


This was a concern for me as well. I am working on implementing native
win32 support. Here's what I envisioned (at that time I knew only of
user, system, and trusted--not security):

0x00    user (insert)
0x80    system
0x40    (delete mode)
0x20    encapsulated
0x10    trusted


What I mean by "encapsulated" is that I wanted to store additional
attributes in this mechanism. I had in mind "virtualizing" FAT and NTFS
attributes like this:

Key                         Description
-----                       --------------
FAT.ATTRIB:BYTE             Basic FAT attributes byte
FAT.TIME:C                  FAT creation time
NTFS.ATTRIB:COMPRESSED      NTFS file compressed flag
NTFS.ATTRIB:ENCRYPTED       NTFS file encrypted flag
...
NTFS.TIME:C                 NTFS creation time in FILETIME format
...


So, these values would have the "namespace" stored within the key name.
But if you change the namespace method to be more generic... This may be
a bit of overkill.


Offtopic here, but I have also been giving some thought on file streams.
As you know, Mac OS X uses multiple file streams, but NTFS does as well.
I've been coming up with a plan to support these things (and of course
I'd be implementing them). Let me know if you're interested in
discussing this.

Thanks,
Wesley





> 
> | Cheers,
> | JB
> 
> Cheers,
> Denis.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFCPyySpC5CI8gYGlIRAl42AJ9X0ec9lCTDPYcdlYAlP4fJooVD6QCfX6OQ
> 7jReRYF6e2zuiU+w/cSGEdQ=
> =JJw2
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Dar-libdar_api mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dar-libdar_api
-- 
Wesley Leggette <lists-+42/j/[email protected]>

GPG Key:         http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE  7614 2A20 5688 F848 9BDD
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCP0B1KiBWiPhIm90RAl+NAJ9BbwhiJT5YsEScN9glcuDYezfXigCeNqr9
mpzQSyPPg5Ep53JJ/C7X1nw=
=RMnw
-----END PGP SIGNATURE-----