(Apologies for beating on a dead horse here...)
I seems like one confusion here is that everyone has a different idea of
what the semantics we're talking about are. I see two main ones:
Hans's: A file, a directory, and an attribute are functionally
equivalent (except for S_ISxxx and hardlinks). That is, /usr/bin/metas
makes sense, and it's not talking about a program called metas. This
also means that /foo/metas/metas might exist and needs dealing with.
Linus's (I think): A directory is just a directory (no attributes and
no read()able data). A file can contain attributes, where attributes
can be "file" attributes or "directory" attributes. That is, a file is
also a subtree with posix-like semantics (except for hardlink stuff).
So doing "touch /tmp/foo; cat /tmp/foo/metas" fails, rather than doing
something that's probably useless. "touch /tmp/foo; touch /tmp/foo/bar;
touch /tmp/foo/bar/baz" fails on the last touch because bar is a file
attribute and recursive magic is disallowed.
Which one are we talking about?
FWIW, I like the latter version a lot better, as it removes a lot of
ambiguity. If I see a path like /tmp/foo/metas/uid, it is either a uid
attribute (i.e. writing it has security implications) or it is a
standard file (i.e. writing it just writes it). But _I can tell which
one_ by fstat()ing /tmp/foo! If it's a directory, than I have either a
named stream called uid or a genuine file called uid (and I can tell
which by fstat()ing /tmp/foo/metas), but if it's a file then I have the
magic uid. And I'm guaranteed that there's no other funny business,
because /tmp/foo is a "file with a subtree," which means that it's not
an attribute. This way I know exactly what I'm dealing with.
As an added bonus, we could have O_NOMETAS which means that "files" may
not be traversed. Then someone who wants to make sure they get a real
file can do it. If recursive files-as-dirs were allowed, that might not
do quite what the caller expected. If you really wanted a directory
with some data attached, but it in dir/.mystuff, because that's probably
what you meant, and any existing tool will do exactly the right thing
with it.
In the former version, AFAIK, I have a mess. In UNIX, a path is a path.
It's trivial to understand and there's no funny business parsing it.
But now a path has a slippery meaning where the token "metas" could be a
plain old token or it could be magic or it could be magic some other
way. The security implications and the possbility for something to
break horribly are scary.
--Andy