It’s not really true that the O_NONBLOCK is attached “to the underlying file”. Ie, if I re-open() the same file in a different process, I won’t inherit the same flags. Rather, in the laguage of susv3, the flags, etc, attach to an “open file description” of which several can refer to the same file, and several “file descriptors” can refer to the same “open file description”.
Interestingly, CYGWIN applies flags such as O_NONBLOCK to file descriptors, not file descriptions (at least it did last time I checked the source, which was some years ago). I’m not aware of any misbehaviour associated with this breaking of POSIX behaviour.
I was just using language sloppily. When I talk about the underlying file I mean the structure representing the open file within the kernel. Of course opening a new file gets an entirely new set of flags.
Thanks for the note on cygwin, interesting that it works. I would have thought it would fail on O_APPEND, at least, but perhaps that state is being recorded in the Windows handle somehow.
I just checked, and it seems the O_APPEND and O_NONBLOCK status are kept with the file descriptor (along with the FD_CLOEXEC, which is supposed to be per-descriptor). This is at least as far as fcntl( …, F_GETFL, …) is concerned — I didn’t check whether the blocking/nonblocking and append/nonappend *behaviour* is set on the underlying open file description, but I’m fairly sure that is not the case.
Do you have some specific situation where you think this would fail? I’d be interested to test.
If you have a significant number of readers now, it’s because they liked what you posted before. It doesn’t make sense to change what you post on your blog for fear of alienating people who only came here because they liked what you posted to start with. Apparently people like your idea of random nonsense.
lev: the kind of case where I would check for failure would be
prog >>foo.txt 2>&1
where prog writes to both standard output and standard error. On Unix all the output should be appended to foo.txt, because the O_APPEND flag, and, for that matter, the file position, will apply to the underlying file structure referenced by both file descriptors. If the O_APPEND flag does not apply, then it seems possible that prog’s output would overwrite itself.
If the file position is shared, but the O_APPEND flag is not, then try a program which opens an existing non-empty file with O_APPEND, dups the file descriptor, calls lseek to change the file position to 0, and then write. On Unix O_APPEND means that the file position is reset to the end of the file before each write, and I assume cygwin does the same. The question is whether this also applies to the dup’ed descriptor, as it would on Unix.
I tested (see below) and cygwin really doesn’t follow Unix. Nevertheless, cygwin has about 2000 packages and *many* users and I’m not aware of any bugs resulting from this misbehaviour. prog >>foo.txt 2>&1 because the dup()d descriptor 2 inherits the append flag from 1 at the time of the dup(). Given the lack of bugs on cygwin, I would suggest that it could be a relatively safe change to make O_APPEND a per-descriptor flag.