On 01/06/2012 06:52 AM, Ron Kerry wrote:
Why should gtar open FIFO files?
The question is not why an archiver opens a FIFO file, but what it does
after opening a file O_NONBLOCK (the TOCTTOU race is eliminated by
switching stat()/open() to open()/fstat() filtering, and once we have
ascertained that an open fd is not a FIFO, if we can then use fcntl() to
remove the O_NONBLOCK, hopefully that will resolve the situation with
DMF).
I am a bit lost in this discussion. As far as I know, O_NONBLOCK has no
effect whatsoever on an open() system call,
Wrong. Per POSIX, O_NONBLOCK on a FIFO controls whether the
open(O_RDONLY) blocks until a writer is present, or succeeds right away;
likewise, open(O_WRONLY) uses O_NONBLOCK to fail to open if there is no
reader. Which means that if you open a FIFO with no writer, you've
blocked the program unless you used O_NONBLOCK. (The same thing goes
for block and character devices that support non-blocking operation, as
well as any implementation extension file types that support
non-blocking; apparently DMF is such an implementation where even
regular files support non-blocking).
POSIX states that the use of O_NONBLOCK on non-FIFO files (more
correctly, files that don't support non-blocking operation) has
unspecified effect on whether fcntl() can observe the bit set, and if
the bit is set, unspecified effects on what it does to reads and writes
on that fd: http://austingroupbugs.net/view.php?id=141
So the question at hand is avoiding the block (using O_NONBLOCK during
open()) while avoiding the unspecified behavior (clearing O_NONBLOCK on
regular files before reading them).
it only has an effect when
you do a read or a write. So you open the file without O_NONBLOCK, you
fstat the file, and if it's a pipe you close it. I do not see the need
for using O_NONBLOCK.
Use of O_NONBLOCK is necessary to avoid hanging while waiting for a
writer, before you ever get a chance to fstat() the fd to see if it was
a FIFO to close it.