Re: reiser4 plugins

[Stefan Smietanowski <stesmi@stesmi.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

>> 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.

Either you're describing another problem than I'm thinking of or
/home/stesmi/.meta/foo 's "file" will always be /home/stesmi/foo .
$dir/.meta/$file and $dir/$file .

Or do you mean something else when you say "parent" ?

Do you mean that if you know $dir/.meta/$foo then you don't know
the meta of the parent?
Won't $dir/../.meta/$end-of-path/.meta solve that?

/home/stesmi/foo <- file
/home/stesmi/.meta/foo <- meta of foo
/home/stesmi/ <- parentdir
/home/.meta/stesmi <- meta of parentdir
/home/stesmi/../.meta/stesmi <- also meta of parentdir

Or is your problem that you don't know "stesmi" ?

Ie you can't figure out what the current dir name is ?

So you can't construct /home/stesmi/../stesmi because you don't
know the name of the dir?

In that case do :
/home/stesmi/.meta/. <- meta of parent. Naturally same as
/home/.meta/stesmi

And if then ".." is mirrored as well is a secondary discussion.
/home/stesmi/.meta/. <- meta of "stesmi"
/home/stesmi/.meta/.. <- meta of "home"
/home/stesmi/.meta/foo <- meta of file "foo"

> 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.
> 
>> I mean, editing something is easy and you don't have to "know" how
>> to navigate /meta
> 
> But then you have to "know" how to navigate .meta, and more importantly,
> how to find .meta

The biggest problem in my eyes is exportability.

>> and you don't have the clash of files vs metadata
>> (is /meta/vfs/home/stesmi/foo a file or an attribute called foo of
>> the dir stesmi ?).
> 
> So, how do I get metadata of a directory?  If the metadata for /home/me
> is in /home/.meta/me, and the metadata for /home is in /.meta/home, then
> where is the metadata for / ?

/.meta/. (look above)

The "." is also inside .meta

>> /home/stesmi/foo <- dir
>> /home/stesmi/.meta/foo <- "dir" containing all metadata
>> /home/stesmi/.meta/foo/attrib <- some attribute called attrib
>> /home/stesmi/foo/bar <- file
>> /home/stesmi/foo/.meta/bar <- "dir" containg all metadata
>> /home/stesmi/foo/.meta/bar/attrib <- some attribute called attrib
> 
> 
> [...]
> 
>> If this has already been taken up, I must've missed it.
> 
> 
> It looks a lot like how I suggested we resolve the ambiguity within
> /meta/vfs, only I called it '...' instead of '.meta'.

Ah. When I read the talk about "..." I mistook it for something else.

I'm sorry.

> Either way, the major challenge to this method is not so much whether
> it'd work, but how to choose a suitable delimiter?  The delimiter must
> be standard if we're going to have apps develop for it, and it must not
> be used in the name of any existing file or directory.

I think "..." and ".meta" both serve as a logical delimiter. However
some programs implement their own "..." which would make it clash with
them. Naturally if some program created a directory called .meta we're
equally screwed.

> I had a long essay here on how '.meta' breaks every recursive operation
> on directories (rm -rf, tar, mkisofs), but I deleted it when I
> remembered that I played around with the alpha/beta reiser4 which had a
> 'metas' dir that did the same thing, but was hidden from the normal
> directory listing.  'cd metas' worked, 'ls metas' worked, but 'ls'
> showed no directory called 'metas'.
> 
> I don't *think* there are any apps that will break if you tell them to
> open a path that doesn't exist in a directory listing.  That is, typing
> 'vim /home/metas/acl' should always let me edit the acl on /home, and
> vim should never complain about how /home/metas doesn't show up in
> /home.  A program would have to be pretty retarded to fail on something
> like that.
> 
> But, we have to support some pretty retarded programs.  That is why I
> like /meta -- the default view is a completely POSIX-compliant tree that
> works with tar, and even the /meta view is POSIX-compliant, even if it'd
> be a bad idea to tar it.  Then we don't have to worry at all about
> stupid programs.
> 
> How much should we be worrying about this particular brand of stupidity?
>  And what's a good delimiter?

Very good points. I don't like it being seperate from the dir though so
I'm more inclined to support having the metas "close" to the file itself
(/home/stesmi/.meta/) instead of seperate from (/meta).

// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFC0tygBrn2kJu9P78RAmBYAJ9YVeAacrREuBFrpGz9Ov5STo6dXwCgxrFi
d2BN/T+//CfIZXPCUN9uhC4=
=6SfT
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/