Hans
http://devlinux.com/namesys describes reiserfs
Kenneth Albanowski wrote:
> On Tue, 25 Aug 1998, Chris Wedgwood wrote:
>
> > 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
-
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