> 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.
What I see here is that lookup_dentry() will... Oh, my. Yes, it will work,
but... Arrgh. I'ld rather change the order of tests in lookup_dentry() and
avoid checking LOOKUP_CONTINUE in the method. By the way, your version
will *not* work for foo/dir/ - it will follow the link ;-)
> (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, I see your point here, but IMO it means only one thing - that we
should stop pretending that those objects are symlinks. They are
different. Yes, we have one more type of object. Call it VFS-link,
wormhole, whatever. We are going to completely unnecessary pains to make
them look like symlinks. What for? Especially if lstat() on them may tell
you that they are directories. It would make a *lot* of sense if we would
simply admit that we have a new type here.
I'm still curious - what are you going to do with rename()? Can the
"default" file be separated from its directory?
-
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/