Re: Error reading EA

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

Wesley Leggette wrote:
| On Mon, 2005-03-21 at 21:20 +0100, Denis Corbin wrote:
|
| 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
|

My current idea is to make namespace transparent to dar. the -u and -U
options would change their meaning becoming a mask option (like -Y and
- -Z for example) but applied to the whole EA name. For example -u
"system.*" would exclude all EA of the system namespace while -U
"security.*" would include only the security namespace. One could also
restore or save only a particular set of EA using several -u or -U
basing the selection on namespace and/or name of the EA.

This implies API changes of course.

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

How to stay portable then? Permission already carry the readonly flag
(which is a fat attribute), time is also carried in dar's archive, (last
modification time, last access time), creation time is not portable, but
can be stored as last modification time for DOS systems. While file
format is a display problem not a storage problem (the same information
has not to be saved twice).

I don't think the EA is a good place to store filesystem specific
information. EA has a quite standard definition and API, what if one day
the "encapsulation" namespace is used somewhere else. In another side,
dar has not to understand the EA meaning or role in the filesystem.

If dar must store the compressed attribute and restore it it must be
done beside this, as new fields. (ext2/3 have several fields, ntfs, fat
have their own fields, macintosh filesystem have a more complex own
structure (the forks)).

There is a choice to make: stay generic and system independant, thus
drop some filesystem specificities but allow inter filesystem exchanges,
or have the knowledge of all the possible filesystem on Earth, and spend
90% of the time maintaing dar to fit each filesystem evolutions, and
loose time considering what would come if one want to restore a file
from a filesystem to another, does this or this attribute (in a very
general meaning) has to be casted to a more or less corresponding one on
the target filesystem?

As you can guess now, my choice is the generic way. Following standards
leads to portability. For that reason I have dropped ext2 attributes
from dar's abilities, nobody complained, yet. Look at dar's venerable
grand brother: tar. It has become the most popular tool used for so long
time... does it knows of all of the filesystems specificities? no. And
is is still used today.

Any objections are welcome :-)

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

As soon as we can have a standard feature, with a standard API I will
say yes. Else, we will loose time an energy, and will make dar less
stable (having to consider many different cases...).

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

iD8DBQFCQzeWpC5CI8gYGlIRAoTFAKCvti6MW74l6MtX503oSjxL6g5LIACfa6sA
G148kInM7tAOSu1SBy7l/ts=
=n49n
-----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