Re: silent semantic changes with reiser4

[Horst von Brand]

Hans Reiser <reiser@xxxxxxxxxxx> said:
> 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.

The design's evolution, and your friend's question, are irrelevant. Might
be a nice story, but not relevant to discuss the _current_ design, its
shortcommings, and possible solutions.

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

Urgh.

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

Oh, so metafiles could have any names at all. Awful.

> This was actually pretty decent as a design,

Could have been worse, true. Not very much, anyway.

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

Bad design. As Ted explained, _any_ "normal" name in there will lead to
legacy applications do the wrong thing unaware of the special status of
this stuff, and this is sure to break things and/or to lead to nasty
security problems.

>                                           and this had the advantage 
> that one could ls it to see all the builtins supported by a given 
> plugin.

What kind of builtins? What is a "plugin"?

>         This is not an important advantage, and I encourage others to 
> critique it.

If it is not important, let's postpone any discussion on it until (if ever)
the important problems are solved.

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

English, please.

> The use of the '..metas/' prefix is purely a non-mandated style 
> convention.

So it isn't mandated, and I could decide placing my own stuff under other
names, willy-nilly? See the comment above on "normal names" being
dangerous; if it hasn't a builtin way of ensuring legacy (or even new
applications) don't trip over this stuff, it is a moby nightmare security
and correctness wise.

>             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

"Common" and "current usage" is important to the average user, "normal" is
crucial for correctness and security,

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

So far, I've seen no real reason to introduce this. If it is scrapped,
there will be no need to talk anybody out of silly ideas.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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/