Timo Sirainen wrote, On 10/19/09 6:11 PM:
On Mon, 2009-10-19 at 17:55 -0400, Timo Sirainen wrote:
Can someone find an OS where the attached program doesn't work? It should print "success". So far tested for success: Linux 2.6, Solaris 10, FreeBSD 7.2, OpenBSD 4.2.
And also: I think (guess) that behavior is required by POSIX, but it would be nice if someone could verify that. :) The behavior being: seeking in a fd is affects all processes that have the same fd open. (Simple IPC, yay.)
As I read them, the various man pages for dup() confirm that. In addition to those man pages' statements about standards compliance, the fact that dup() is in 4BSD's unistd.h is also a strong clue. When looking for this sort of info, an invaluable resource is the man page archive at http://www.freebsd.org/cgi/man.cgi which has man collections from many different branches of the Unix family tree going back to Unix 7th edition and BSD 2.8.
It is useful for people who don't routinely work with file access code to note that "same fd" means significantly more than "same file" so it isn't as simple as having processes open() the same file. One man page for dup() says this:
The object referenced by the descriptor does not distinguish between
fildes and fildes2 in any way. Thus if fildes2 and fildes are
duplicate references to an open file, read(2), write(2) and lseek(2)
calls all move a single pointer into the file, and append mode,
non-blocking I/O and asynchronous I/O options are shared between the
references. If a separate pointer into the file is desired, a
different object reference to the file must be obtained by issuing an
additional open(2) call. The close-on-exec flag on the new file
descriptor is unset.