> On Mon, Aug 24, 1998 at 05:30:51PM +0200, Andi Kleen wrote:
>
> > In article <35E178D3.CBFC4174@flashnet.it>,
> > "Sebastiano Tine'" <mb027878@flashnet.it> writes:
>
> > > I have named it "Meta File Information". They consists in data
> > > associated with the single file that user process can set and
> > > read.
> >
> > > Does anyone ever thinked on it or implemented in some way ? I
> > > need tips and suggestions on possible implementations.
> >
> > It is already implemented. It is called a "directory".
>
> Yup... and IMO its a good way to do it.
>
> MacOS files can fork into two - but why two? Is two really that
> special in this case? And why can't these forks have forks?
Last time I was reading through the specs, it appeared that there can be
any number of forks, theoretically, in the filesystem. But they cannot
nest, and I'd be astonished if the OS actually supported more then two
forks per file.
> NT has multiple forks, but those forks can't fork, etc.
NTFS, you mean. OS/2 (HPFS, but also some hacks to support this on DOSFS)
also has forks, to some degree -- its "extended attributes" allow a lot of
data to be stored along with a file, though they are more similar to an
individual resource file then a set of forks.
> I though about this one for a long time once when I was keen on the
> metadata idea and decided directories are the most sane way of doing
> this. If you want fancy stuff, then make a library that know how to
> handle different bits in each directory, etc.
Yes, once you go to nesting forks, you might as well call the things
directories, and be done with it. (And deal with the efficiency
consequences of this -- reiserfs, anyone?)
You still are stuck with breaking normal utilities, though, unless you
provide some integral way of wrapping the "bundle" up into a flat file, if
you try to read directly from the forked "directory". (But even that won't
work, as something wanting to read a .c file probably just wants the "data
fork", never mind the extra data. You can't win, really, at least not
without making "ar", "cp", and "tar" much more special.)
> I think NeXT did something like this?
To the best of my knowledge, no. They just have a resource format (".nib",
I believe) that is easy to work with, much as if a Mac resource fork were
stored in a separate file.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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