On Sun, 11 Jun 2000, Alan Cox wrote:
> > Except that we don't know which directory should be locked. Alan,
> > original implementation (in BSD) followed links on every operation.
>
> I dont see the problem. You follow the link. At that point you worry about
> creating an object. The race there is a userspace issue.
There are kernel races. BTW, you do realize that in our case following
link != reading the contents and doing lookup?
> > except that one. Notice that O_EXCL is different: plain O_CREAT applied to
> > a normal symlink will happily open the targt, with O_EXCL it will return
> > -EEXIST. IOW, in case of O_EXCL we are asking for a different behaviour
> > which happens to prohibit following broken links for a different reason.
> > It doesn't remove the reasons for doing the same without O_EXCL.
>
> Compatibility, history, not breaking emacs..
>
> > In other words, in that case POSIX draft is broken and we would be
> > better off fixing that bug instead of casting it in stone. Behaviour in
> > question is inconsistent with every other case when links are
> > created/removed/renamed.
>
> You might want to take that up with the relevant posix committee then
What an elegant way of sending somebody to hell... ;-) Seriously, I think
that at the very least we should get something along the lines of
"portable programs can not rely on creat(2) turning dangling symlinks into
normal ones" in there. Any clues on how one deals with POSIX committees?
Aside of "take a ten-feet pole...", that is.
-
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 : Thu Jun 15 2000 - 21:00:23 EST