RE: Linux 2.1.125 doesn't dump core on SIGSEGV

Torbjorn Lindgren (tl@fairplay.no)
Thu, 12 Nov 1998 11:20:44 +0100 (CET)


On Wed, 11 Nov 1998, Eastep, Tom wrote:
> From: Chris Wedgwood [mailto:chris@cybernet.co.nz]
>
> >Implicit O_NOFOLLOW when we use O_CREAT|O_EXCL is a somewhat
> >arbitrary rule which we will no longer need - so IMO, removing this
> >`restriction' is the right thing to do.
>
> FWIW, the 2.1.127 behavior wrt O_CREAT|O_EXCL is exactly what we implemented
> here at Tandem and what Solaris does -- if a symbolic link with the
> specified name exists, the operation fails with EEXIST.

It's definitely in Single Unix Specification v2, here's some excerpts from
the man-page for open():

int open(const char *path, int oflag, ... );
[...]
O_EXCL
If O_CREAT and O_EXCL are set, open() will fail if the file exists.
The check for the existence of the file and the creation of the file
if it does not exist will be atomic with respect to other processes
executing open() naming the same filename in the same directory with
O_EXCL and O_CREAT set. If O_CREAT is not set, the effect is undefined.

Pretty clear what the expected behavior in Single Unix Specification, v2
is. I don't have any POSIX documentation, but exactly what is O_EXCL
supposed to do if it doesn't do this?

It's also consisten with the documented behavior of O_EXCL for all
the other calls that support it in Single Unix, sem_open() / mq_open() /
shm_open() all do the same thing with it, and it isn't used for anything
ELSE, so if it doesn't do this it doesn't do anything at all!

(Checked with their word search engine, there are only five distinct
references to O_EXCL in all of Single Unix Specification v2, namely
fcntl.h and the four calls I have mentioned...)

-
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/