Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 14 Sep 2004 00:27:37 -0400 | From | Andy Lutomirski <> | Subject | file-as-dir vs. dir? (was Re: silent semantic changes with reiser4) |
| |
(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 - 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/
| ![\](/images/icornerr.gif) |