Re: silent semantic changes with reiser4

From: Stephen Wille Padnos
Date: Thu Aug 26 2004 - 21:09:58 EST


Hans Reiser wrote:

Nikita Danilov wrote:

Christophe Saout writes:
> Am Freitag, den 27.08.2004, 01:45 +0400 schrieb Nikita Danilov:
> > > > At least in reiser4 they don't have, or at least you can't access them.
> > > > They do.
> > > > > ln -s foo bar; cd bar/metas shows me the content of foo/metas.
> > > > That's because lookup for "bar" performs symlink resolution.
> > So I can't access them and it is pointless. ;-)
> > BTW, I can do a cd metas/metas/metas/metas/plugin/metas... I don't think
> this makes sense. :)

Why? foo/metas is a file system object just like foo. It has owner,
permission bits, so access to its meta-data should be provided, and
uniform way to provide access to the file system object meta-data is to
have these little magic files inside metas directory, which is a file
system object just like metas. It has owner^@^@^@^@*** - Lisp stack
overflow. RESET

Nikita.

> -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




I think Christophe is a bit right here. While in general having meta-meta objects makes sense, in this particular instance, I don't see the functional need for it. Can you supply an example of where it would be useful?

One example is to supply hints about what to do with the attribute if the file is copied / moved.
Several types of attributes have been mentioned:

1) Those that are essentially a cached object, which can be re-derived from the source file (e.g. thumbnail image)
2) Those that become invalid if the source file changes (e.g. hash value)
3) Those that should be maintained on file copy (e.g. author, copyright, etc)
4) Those that may not want to be copied with the file (e.g. security keys or the like)
etc.

This could be accomplished without meta-meta information (like permissions), but that wouldn't be very extensible, would it :)

- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/