[Dar-libdar_api] Re: Error reading EA
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
|
From: Denis C. <dar...@fr...> - 2005-03-24 21:57:09
|
-----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----- |