Thread: [Dar-libdar_api] Re: Error reading EA
For full, incremental, compressed and encrypted backups or archives
Brought to you by:
edrusb
Menu
▾
▴
dar-libdar_api
|
From: Johnathan B. <jk...@us...> - 2005-03-21 17:32:08
|
Hi Denis,=20
=46rom the dar-support list archive, message of 2005-03-01 12:30:=20
> | They explictly mention the security namespace but I don"t know at all
> | if this is standard.
=20
> 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 wa=
y=20
to implement EA support in libdar in a more general way, that is independen=
t=20
of specific namespaces...
Cheers,
JB
=2D-=20
Johnathan K. Burchill, Ph.D.
jk...@us...
|
|
From: Denis C. <dar...@fr...> - 2005-03-21 20:24:13
|
-----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... :-) | 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----- |
|
From: Wesley L. <li...@ka...> - 2005-03-21 21:34:18
|
On Mon, 2005-03-21 at 21:20 +0100, Denis Corbin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Johnathan Burchill wrote: > | Hi Denis, >=20 > Hello Johnathan, >=20 > | > | 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... > | >=20 > 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 >=20 > | Cheers, > | JB >=20 > Cheers, > Denis. >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iD8DBQFCPyySpC5CI8gYGlIRAl42AJ9X0ec9lCTDPYcdlYAlP4fJooVD6QCfX6OQ > 7jReRYF6e2zuiU+w/cSGEdQ=3D > =3DJJw2 > -----END PGP SIGNATURE----- >=20 >=20 >=20 > ------------------------------------------------------- > 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=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Dar-libdar_api mailing list > Dar...@li... > https://lists.sourceforge.net/lists/listinfo/dar-libdar_api --=20 Wesley Leggette <li...@ka...> 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 |
|
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----- |
|
From: Wesley L. <li...@ka...> - 2005-03-24 22:50:13
|
On Thu, 2005-03-24 at 22:56 +0100, Denis Corbin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > 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 a= ll > | |>| 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 b= e > | 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 > | >=20 > 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. >=20 > This implies API changes of course. >=20 > | > |> What I mean by "encapsulated" is that I wanted to store additional > |> attributes in this mechanism. I had in mind "virtualizing" FAT and NTF= S > |> 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 > |> ... > | >=20 > 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). >=20 > 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. I should stress that what I'm suggesting only uses the EA code, but the "encapsulated" flag indicates it is not a real EA. More below. >=20 > 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)). >=20 > 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? >=20 > 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. >=20 > Any objections are welcome :-) I see your point and agree with it. That is exactly why I thought storing these "non-standard" (non-Posix) values as "Attributes" would be good. I.e., instead of extending the catalog entries to add more values for each system, if an archive is created on a specific system, it can store those non-standard values as "fake" attributes (thus, the "encapsulated" meant that they are not really attributes that would be restored on a Linux system, they are just values that OS specific implementations could restore if they wanted). So, here's how I would envision it: You have libdar on WIN32. You back up some files, and they all have these "encapsulated" attributes with them. But of course, they are really just optional non-standard information. Then, you take that archive to a linux machine. There, maybe the fact that these WIN32 values are present is displayed to the user, or maybe not. Regardless, they are not restored to the hard drive. Instead, just the standard Posix values are. Then, maybe you take this same archive to another WIN32 machine. Here, these "encapsulated" values could be restored. See? So it's an extensible system where all non-standard information would be stored in key/value pairs. Any values that an implementation doesn't understand can be ignored, and any missing values will be made up from the posix standard data (like r-x would equal the read-only flag). This is sort of how RAR and ZIP do it, but they used fixed extensions. I think this is more flexible. As far as Mac OS X is concerned: Yes, the forks would have to be saved. Note also that NTFS uses alternate data streams (which are very similiar to forks). Thus, if dar was able to save forks, it would kill two birds with one stone. I propose adding full multiple data stream support. Basically, how this would work is similiar to the ideas presented in Reiserfs 4. Each file acts as a sort of "directory" containing multiple other entries. I would propose a special "stream" entree type, and perhaps the EOD entree could end a listing of streams after a file_stream entry, or something like that. As far as all that goes, I should note that the reason I've been writing up a detailed specification of dar edition 3 (and I'm going to write the edition 4 specs soon) is that I want to propose changes to incorporate the features I mention above. I intend to be crystal clear about what the changes would be and what the API would be to access them. I am working on documenting the private API for the same reason. >=20 > | > |> 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 stream= s. > |> As you know, Mac OS X uses multiple file streams, but NTFS does as wel= l. > |> 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. >=20 > 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...). Noting my work on documentation, yes, I agree fully. My main efforts right now have been focused on documenting the file format and the private API for just this reason. After the current API is documented, I will document the proposed changes. This way, we can come to some consensus before any implementation. And of course, in the worst case, at least there will be some useful documents of the current system ;) Well, thanks, Wesley >=20 > | > |> 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 >=20 > iD8DBQFCQzeWpC5CI8gYGlIRAoTFAKCvti6MW74l6MtX503oSjxL6g5LIACfa6sA > G148kInM7tAOSu1SBy7l/ts=3D > =3Dn49n > -----END PGP SIGNATURE----- >=20 >=20 >=20 > ------------------------------------------------------- > 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=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Dar-libdar_api mailing list > Dar...@li... > https://lists.sourceforge.net/lists/listinfo/dar-libdar_api --=20 Wesley Leggette <li...@ka...> 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 |
|
From: Denis C. <dar...@fr...> - 2005-03-30 19:54:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wesley Leggette wrote: | On Thu, 2005-03-24 at 22:56 +0100, Denis Corbin wrote: | |[...] | |> I should stress that what I'm suggesting only uses the EA code, but the |> "encapsulated" flag indicates it is not a real EA. More below. Yes, but if this "encapsulated" is note real EA how could it use real EA code? So we have different action depending on the domain of the EA which is not the case today (dar's code is EA-domain independent). | |[...] | | Any objections are welcome :-) | | |> I see your point and agree with it. That is exactly why I thought |> storing these "non-standard" (non-Posix) values as "Attributes" would be |> good. I.e., instead of extending the catalog entries to add more values |> for each system, if an archive is created on a specific system, it can |> store those non-standard values as "fake" attributes (thus, the |> "encapsulated" meant that they are not really attributes that would be |> restored on a Linux system, they are just values that OS specific |> implementations could restore if they wanted). Whatever is the way theses filesystem specific informations are stored in the archive (through a "encapsulated" EA or on their own beside other inode informations), we still have the problem of specific code for different filesystem. Let's take the read-only notion as example: Under Unix this is stored with the permission (user/group/other write access off), under DOS this is a file attribute. How to restore a r--r--rw- file under DOS then? Now you can extrapolate to Macintosh forks, and so one. Storing filesystem specific information has heavy consequences in portability and probably also in stability of the application, as much as more different filesytems are handled in their specificities. Because there will not be a generic way to handle a file whatever is the filesystem it comes from and it goes to (which what we have today). | |> So, here's how I would envision it: | |> You have libdar on WIN32. You back up some files, and they all have |> these "encapsulated" attributes with them. But of course, they are |> really just optional non-standard information. | |> Then, you take that archive to a linux machine. There, maybe the fact |> that these WIN32 values are present is displayed to the user, or maybe |> not. Regardless, they are not restored to the hard drive. Instead, just |> the standard Posix values are. what about the read-only property? | |> Then, maybe you take this same archive to another WIN32 machine. Here, |> these "encapsulated" values could be restored. See? Yes I see. So you should have as much encapsulated domaine as there is filesystem with handled specificities. Assuming you save the 'sync' ext2 attribute (which is not the case today), as it is ext2 specific, you should have to store this information in an EA of an "encapsulated" domain, but not the same "encapsulated" domain as the one handling the System/Archive/Read-Only attributes found in FAT filesystem. What about the ext2 'dump' attribute then, it is the FAT's "Archive" attribute equivalent. Which domain would it be stored in? This also raise the filesystem detection problem. How to know which fileystem is used in a portable way? Because of course you must know which "encapsulated domain has to/can be restored. Moreover it must be detected file by file, if for example you mount a fat16 partition on a ext2 filesystem, and also have an iso9660... | |> So it's an extensible system where all non-standard information would be |> stored in key/value pairs. Any values that an implementation doesn't |> understand can be ignored, and any missing values will be made up from |> the posix standard data (like r-x would equal the read-only flag). The idea to have a set of attributes that is used by thoses implementation that know about it an ignored by others implies several implementations. now, having different applications, is what we have for HTML when a browser ignores marks it does not know. As you can see with HTML, it does not displays the same way from browser to browser, this has minor importance because the target is the human eye and human can interprete what it sees. But Dar's target restoring files is not human eye, but computer's filesystems, and behind theses, are computer applications that use theses files. Filesystems as well as computer applications do not have the same ability to interprete what the use. I am affraid that one saved file could result in slightly different restored files depending on filesystem it is restored on and depending on dar's implementation and operating system used. Rewriting dar to natively use windows system is one thing. Making a different implementation to add extensions is very different. This is what Microsoft did with HTML, that finally ruined HTML standard as much web site's use Microsoft's extensions, you know, those web sites where you can see: "your browser is not supported, you need to use Microsoft's IE version 6.2". This is quite the opposite of the original idea of HTML, where it was planed to be browser and system independant. | |> This is sort of how RAR and ZIP do it, but they used fixed extensions. I |> think this is more flexible. | do ZIP and RAR save FAT attributes? do they save ressource forks? Do they save ext2 file attributes? I am not sure of that. Even if they do, what would be the use of having a cross platform application if they only can restore in a portable manner what dar handles today? | |> As far as Mac OS X is concerned: Yes, the forks would have to be saved. |> Note also that NTFS uses alternate data streams (which are very similiar |> to forks). Thus, if dar was able to save forks, it would kill two birds |> with one stone. | |> I propose adding full multiple data stream support. Basically, how this |> would work is similiar to the ideas presented in Reiserfs 4. Each file |> acts as a sort of "directory" containing multiple other entries. I would |> propose a special "stream" entree type, and perhaps the EOD entree could |> end a listing of streams after a file_stream entry, or something like |> that. | |> As far as all that goes, I should note that the reason I've been writing |> up a detailed specification of dar edition 3 (and I'm going to write the |> edition 4 specs soon) is that I want to propose changes to incorporate |> the features I mention above. I intend to be crystal clear about what |> the changes would be and what the API would be to access them. I am |> working on documenting the private API for the same reason. So we would end with many different implementations, one working for Mac OS (saving forks), one for DOS/windows (saving DOS attributes) one for NTFS and so on. Why then not using existing backup tools on theses systems, why taking dar for that? There is no more need of portability, which is what dar brings. | | | | | | |> 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...). | | |> Noting my work on documentation, yes, I agree fully. My main efforts |> right now have been focused on documenting the file format and the |> private API for just this reason. After the current API is documented, wasn't it? ;-) |> I |> will document the proposed changes. This way, we can come to some |> consensus before any implementation. And of course, in the worst case, |> at least there will be some useful documents of the current system ;) | | |> Well, thanks, |> Wesley | |[...] Cheers, Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCSwNYpC5CI8gYGlIRAgh5AKCA9LYzixfjDVwZQGHbqMFTtjcxdwCeLR0I r6p+1dnNtNw4gsQBpXIMfCo= =hVPI -----END PGP SIGNATURE----- |
|
From: Denis C. <dar...@fr...> - 2005-05-08 12:47:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Denis Corbin wrote: | 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... :-) | | |[...] | | 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. | [...] This is now implemented under the CVS trunk. The documentation, man pages, API tutorial and doxygen comments are up to date. Rawly, this has been done as explained above, EA namespace is now transparent to dar, for libdar, a mask replaces the ea_root and ea_user switchs to defines which EA to consider. For dar, the -u and -U options have changed and now take an argument. Cheers, Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCfgpHpC5CI8gYGlIRAmGFAKC9Grn6I80afJJwejDiw+XwMbIHUwCgtcyG 4DWa5sUsU+Ji80XXEzoK3cQ= =zxwO -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X