On 11 Jun 2000, Ulrich Drepper wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> > > 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
>
> Symlinks are not in the current POSIX standard and therefore the
> existing POSIX standard is OK. Symlinks are coming in the next
> revision of the standard as an option (due to the merging with the
> Unix specs). If you find something inadequate in the Austin group
> draft tell me what it is and a solution for it. I'll make sure it
> gets handled in the next meeting.
You are welcome. Case in question: foo/bar/baz being a dangling symlink,
open() with O_CREATE applied to it. Behaviour mandated by the draft:
create a file in place where symlink points to. Problem: it is wildly
inconsistent with every other case when we create/remove/rename objects.
In every other case it's "you've got foo/bar/baz, you either
create/remove/rename the entry 'baz' in directory 'foo/bar' or fail".
Here the operation is applied to directory potentially different from the
foo/bar.
Proposed (minimal) change: "Portable programs can not rely on
open()/create() following dangling links. It should not be confused with
O_EXCL semantics - there we refuse to follow _any_ symlinks, as well as
open existing files."
In other words, proposed semantics looks so:
a) Broken symlinks are never followed.
b) Normal symlinks are followed unless we have O_NOFOLLOW
c) If O_EXCL is passed we refuse to open existing file, be it a result of
following a symlink or not.
-
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