[Dovecot] testing needed

[Bill Cole]

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.