On Monday July 11, [EMAIL PROTECTED] wrote:
> Stefan Smietanowski wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >>Ok, still haven't heard much discussion of metafs vs file-as-directory,
> >>but it seems like it'd be easier in metafs.
> >
> >
> > Why not implement it inside the directory containg the file ?
> >
> > Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
> >
> > This should be suit both camps I'd think?
>
> You still need to figure out the parent of "foo", which isn't
> necessarily easy, especially considering that even if we store a link to
> the parent, it will be inside the metadata. Then you have a
> chicken-and-egg situation.
>
> Both camps seem to want to allow easy access to the metadata of a file,
> whether we're given that file as an inode or as a pathname. That's why
> I suggested /meta/vfs and /meta/inode -- sometimes I want to look up a
> file by name, and sometimes by inode, but either way, I should be able
> to get its metadata.
Well, it's not really 'as an inode or as a pathname'. It is 'as an
open file descriptor or as a path name' which is an important
difference.
Maybe it is worth repeating Al Viro's suggestion at this point. I
don't have a reference but the idea was basically that if you open
"/foo" and get filedescriptor N, then
/proc/self/fds/N-meta
is a directory which contains all the meta stuff for "/foo".
Then it is trivial to get the 'meta' stuff given a filedescriptor and
if you have a pathname, you can always get yourself a filedescriptor.
Then to allow
cat /home/friend/foo/.meta.../perms
you write a little .so which redefines open, stat, and a few others to
scan for ".meta..." in the pathname and to the necessary magic, and
export LD_PRELOAD=/that/.so
Finally you write a killer app which fundamentally relies on this
functionality, get everyone addicted to it, and *then* (and only then)
start trying to get this functionality into the kernel.
i.e. prototype new semantics in userspace.
NeilBrown
