On Mon, 19 Jun 2000, Neil Brown wrote:
> "For every complex and subtle problem,
> There is a simple and obvious solution.
> Which is wrong."
>
> Sometimes, there is also one which is right.
> I'll let you be the judge as to where the following should fit.
>
>
> It seems to me that there are two sorts of symlinks.
> 1/ those for which "follow_link" is implemented by passing the result
> of "readlink" to "vfs_follow_link" and
> 2/ those for which it isn't.
>
> We could describe these two sorts in other ways:
>
> 1/ Those which can safely be exported via NFS (which asserts that the
> client interprets symlinks) and
> 2/ Those that cannot.
>
> or
>
> 1/ Those for which it makes some sort of sense for create to succeed
> through a dangling symlink and
> 2/ Those for which it doesn't.
>
>
> It seems to me that this distinction should be more obvious - raised
> out of the individual filesystems and presented to the vfs (and hence
> nfsd) layer.
>
> This could easily be done by allowing that if follow_link is NULL, and
> readlink is != NULL, then it is a type-1 symlink, but that if
> follow_link != NULL, it is a type-2 symlink.
No. Consider it vetoed. By me and by Linus - such variants had been
proposed and Linus was adamant on that. That will not go into the tree.
That most definitely will not go into my tree. And yes, that _is_ just bad
enough to force me into forking the tree if you will ever manage to tie
Linus down and get that into ftp.kernel.org one.
_IF_ (very big if) that semantics should be preserved at all the proper
way to do that is to make ->follow_link() honor LOOKUP_POSIX_IN_COLON
in nd->flags. vfs_follow_link() should convert that into LOOKUP_PARENT
fed to walk_path(). open_namei() should still use LOOKUP_PARENT +
lookup_hash(), but then it should pass LOOKUP_POSIX_IN_COLON to
do_follow_link() and repeat the process starting from lookup_hash().
Procfs ->follow_link() should detect the perversion and set LAST_DONE,
breaking the loop in open_namei() (thanks $DEITY, result of that can't be
a symlink itself).
-- Rude? Who, me?- 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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:16 EST