Messages in this thread | | | Date | Sun, 20 Jun 1999 12:09:41 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: I discussed reading directories as files with jra, Stallman, and loic |
| |
On Sun, 20 Jun 1999, Alexander Viro wrote: > On 20 Jun 1999, Linus Torvalds wrote: > > > I don't think that is true. I think the directory and the file should be > > considered separate, it's just that "lookup()" can find one or the other > > depending on use.. > > lookup()? It will confuse the living hell of dcache lookups, for one.
No, the dcache would actually have the thing explicitly as two separate entries: the directory entry would be one entry, and the "default" thing would just be the entry that gets looked up.
> Elaborate, please. What is the parent dentry of file that happens to have > the same name as a directory? What happens upon rename() over (or from) > it? I'm not asking about the implementation - just about the semantics you > want for those objects. What do you want to see if it is NFS-exported? > What do you want to have upon d_path() of such animal?
Think of it as a extension of "follow_link": directories on this kind of filesystem would have special follow-link semantics. So you'd have a directory like this
dir/ default other more_other ABBA_rulez_disco ...
and then "dir" would just have a follow-link function that looks something like this:
if (flags & LOOKUP_CONTINUE) return dir; dput(dir); return default;
See? _Internally_ it would be a true tree, and it's only the act of name lookup that has this magic follow-link behaviour.
(This, btw, is yet another reason why I have never accepted patches that think that "readlink" and "follow_link" are somehow related. I have never thought that they have any real relationship apart from a "UNIX semantics" kind of relationship).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |