> Date: Tue, 1 Sep 1998 19:07:59 -0400 (EDT)
> From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
> Then we must forget about ACLs, privs, the immutable bit...
> We should be using 14-character unix filenames too. No, make
> that 8.3 case-insensitive filenames. We must be portable!
>There's a difference between metadata which is used by the kernel ---
>ACL's, privs, the immutable bit, etc. --- and metadata which is used by
>higher-level applications. Metadata which is used by the kernel or the
>filesystem should be stored in the filesystem; there's no argument there.
>And yes, there is an issue with how you preserve ACL entries and
>privileges with tools like tar and cpio. (There are some solutions;
>trusted HP-UX has thought about this solution, and has a relatively
>elegant solution which we can steal.)
There are differences between kernel metadata and other metadata. Much
kernel metadata (timestamps, various bits) fit in a fixed struct and is
stored as such. But consider ACL's. They can get very long in the worst
cases, so storing them as variable-length data makes sense. Just like the
file data itself. A kernel interface for manipulating ACL's seems
necessary.
If this interface is done right, then it can be used for storing other
metadata as well, without complicating the kernel further.
Consider the extended attributes in os/2. I don't say that is the perfect
solution, but it is an example of what I mean.
ACL's and other metadata are all stored in the extended attributes.
>However, for metadata which is used by desktops and applications ---
>icons, file types/class, etc. ---- I don't believe we the kernel should
>providing such interfaces. In the first place, there's no value added by
>having the filesystem do it, as opposed to a user-mode shared library.
>In the second place, it adds unneeded complexity to the kernel and the
>filesystem. Finally, applications which take advantage of such a scheme
>become inherently unportable, and this is not particularly useful.
>Also, keep in mind that Internet Protocols like ftp and http simply don't
>support files with multiple data streams. So if we start encouraging the
>use of such features, we can easily end up up in a situation like MacOS,
>where you have to use cumbersome tools like binhex before you can ship
>MacOS files across the Internet without breaking them.
ftp problems depends on what we store as metadata. The main data is the
file itself, which will be transferred. Loosing an icon, someone's editor
position, the ACL's for a foreign system is
no big deal. If metadata use becomes common enough then ftp etc. will be
extended to deal with it. Only non-essential stuff (but useful locally)
will be stored as metadata as long as it isn't common everywhere.
Using an utility when we want to transfer metadata isn't
necessarily so bad. Much of the stuff we get is in .tar.gz or similiar
format already. tar/gzip could then be modified to take care of the
metadata.
I like the idea of the file that is a subdirectory too.
There are few changes to the filesystem layout. Utilities
like tar and mv can deal with it. Many programs can access the metadata
without knowing about it. I.e. a file's icon can be edited with any old
image editor opening "filename/icon".
Helge Hafting
-- ----------------------------------------------------------- helge.hafting@daldata.no -----------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html