Re: Error reading EA

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



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30