Re: silent semantic changes with reiser4

Hans Reiser
2004-09-10T05:23:04Z

A friend asked me a question, and because he is very bright it reminded
me that I have not done a good job of reviewing the history of the
design's evolution.

He asked me, why not just access a filename's size as filename/size?

So, the original idea was to access metafiles as just files within a
directory, and it actually remains that way. However, I first decided to
make the standard unix metafiles less intrusive on the namespace. So
that led to calling it filename/..size and filename/..owner, etc. In
this scheme, the use of '..' was just a style convention for metafiles,
and not a requirement in anyway.

This was actually pretty decent as a design, but then a user on the
mailing list suggested replacing the '..' prefix with a subdirectory
prefix. I forget who suggested this and what the prefix was exactly. So
we then created a '..metas' subdirectory, and this had the advantage
that one could ls it to see all the builtins supported by a given
plugin. This is not an important advantage, and I encourage others to
critique it.

So, instead of filename/size we have filename/..metas/size. The only
thing gained by this is that 'size' has a rarer name of '..metas/size'.
The use of the '..metas/' prefix is purely a non-mandated style
convention. File plugins that dislike it are free to violate the
convention. There is no deep semantic to it, just a cowardly aversion to
intruding on current namespace usage with something as common as 'size'.
It has the significant disadvantage of being a longer name than 'size'
or '..size'. I could be talked out of it.

Hans