Messages in this thread | | | From | (Matthias Urlichs) | Subject | Re: Implementing Meta File information in Linux | Date | 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
| |