Re: Re: Error reading EA

On Thu, 2005-03-24 at 22:56 +0100, Denis Corbin wrote:
> -----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.

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.

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

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.


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


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCQ0ZDKiBWiPhIm90RAm+DAKCJ5REQmGs1PU9pusETcL/FXueU2wCgmdHJ
ckAJLHAGs7b3eikKjd6Jjy4=
=q5D8
-----END PGP SIGNATURE-----