Re: Implementing Meta File information in Linux

Matthias Urlichs (smurf@noris.de)
7 Sep 1998 16:51:34 +0200


Raul Miller <rdm@test.legislate.com> writes:
> Elliot Lee <sopwith@redhat.com> wrote:
> > Did I forgot to bash any other approaches? ;-)
>
> You forgot the "embed it in the file" approach.
>
Bad idea, IMHO. We want the non-meta data to be readable with the usual
semantics, i.e. read and lseek do what they are specified to do, for _all_
file formats.

> Of course, to write a file you'll have to train your system to
> deal with a lot of common file formats, and the meta-data will
> probably look ugly in a standard editor.
>
You'll have to train _all_ your utilities, i.e. you need to use a preload
library. NO WAY, especially for non-Linux/Slowaris platforms which don't
have these in the first place.

IMHO, we should start with specifying what the solution should look like.

- access to normal files must be identical whether or not the file has
attributes or whatever (i.e. no AppleSingle solution where the metadata
for a file reside at the beginning of said file, no "the file's data are
really in the file 'filename/data'"),
- a normal recursive directory copy (via NFS, or whatever) will also copy
the metadata
- there should be no visual clutter (i.e., no AppleDouble solution, where
the metadata for "foo" reside in "%foo" or "foo.res")
- no kernel hack, because the solution needs to work on systems where we
cannot _do_ any kernel hacks.

The only solution I can think of which supports all of these is to use some
sort of dot.directory.

-- 
Matthias Urlichs      |        noris network GmbH      |       smurf@noris.de
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
If there must be trouble, let it be in my day, that my child may have peace.
                                                            -- Thomas Paine

- 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.tux.org/lkml/faq.html