Re: file as a directory

[Hans Reiser <reiser@namesys.com>]

David Masover wrote:

> Peter Foldiak wrote:
> | On Tue, 2004-12-14 at 17:24, Hans Reiser wrote:
> |
> |>Peter, I think you are right, though it might be useful to have the
> |>default be dirname/..../glued and to allow users to link
> |>dirname/..../filebody to
> |>dirname/..../something_else_if_they_want_it_to_not_be_glued, and to have
> |>dirname/..../filebody or whatever it is linked to be what they get if
> |>they read the directory as a file.
> |
> |
> | Yes. I assume you mean that dirname in itself should always be
> | interpreted as dirname/..../glued, which by default would be a linked to
> | dirname/..../filebody, the latter being the file content, right?
>
> I think he means the other way.
>     cat foo
> is the same as
>     cat foo/.../filebody
> where "filebody" is some sort of link to (maybe) foo/.../glued.
>
> Understand that you want to allow "normal" files which are not "glued"
> anything, but also "glued" files which are composed of sub-files.
>
> | Also, a pseudofile (e.g. dirname/..../structure ?) could be used to
> | specify how the files should be glued together. A simple question is,
> | for instance, what separators to use between the components, and what
> | ordering to use when putting the component objects together. (This
> | pseudofile could also determine more complicated ways of composing
> | objects.)
>
> If the filesystem does caching, I'd rather have a type of executable
> which, read normally, appears as a stream of its own standard output.
> You'd get the actual file as something like bar/.../source.

Interesting....

>
> This could be done with pipes and daemons, but it's not as easy to
> manage and seems impossible to do as efficiently (with built-in caching,
> etc.)

Explain the value of caching executable output more please.

>
> | The component objects themselves could be full objects, so they
> | themselves could have sub-components.
>
> Right.
>
> Also, there should be an inverse. For instance, a file-as-directory type
> object should have a "contents" object, usually a normal directory, but
> which could conceivably be any type of object, including a code-ish
> object which implements a filesystem. Accessing foo/ would be the same
> as accessing foo/.../contents, only because "..." (or whatever we use
> for meta-files) is outside the actual directory namespace,
> foo/.../contents/... refers to the metas of object "contents", which are
> different than the metas of object "foo".

Are you sure that having more than one "...." is needed?  Hmmm, 
interesting, must think about it.

>
> These two steps essentially create userspace "plugins", and do away with
> having to mount other kernel layers such as lufs (or whatever its
> current implementation is).

I don't follow this point above.

> It does have one important implication, though:
>
> It's important that "metas" or "..." or whatever we've decided on should
> _not_ be mutable by a "userspace" plugin that I have described, nor
> should any meta-files created by kernel plugins. There would be other
> security implications, of course -- user should still not be able to
> create files that are owned by other users and setuid. I'm not sure
> where such checks should go, but we want mortal users to be able to add
> whatever plugins they want, while super-users can feel safe using the
> metas interface to manipulate user files.
>
> I think the issues with directory-as-a-file were the same problems you
> get when you allow hardlinked directories -- that you'd eventually have
> to ditch reference counting for a garbage collector, which is hellishly
> impractical. I don't have a solution to that, other than dropping
> hardlinks entirely.

This issue is overblown.  Other fields have solved this problem. 

>
> Hmm. Why do we need hardlinks? I forget.