Matthew Dillon wrote:
> :This was not my impression; I thought that children had
> :their own descriptor entries on a per-process basis, but
> :that they all pointed to the same open file entry when
> :inherited.  I was contemplating adding a
>     They do indeed point to the same file entry.  Also, when
>     you dup() a descriptor the two descriptors are pointing
>     to the same file entry.
>     This means that they share the same seek offset... seeking
>     in one descriptor changes the seek position in the other
>     descriptor and even the other descriptor in the other
>     process.
>     UNIX has been broken this way from day 1.  It was a major
>     design mistake.
>     The only way to get your own descriptor seek offset is to
>     open() the file again.

After you said this, I found it so hard to believe that I had
to go look.

All I can say is, well I'll be damned; you could knock me over
with a feather, and that doesn't happen often.

I'm sure SVR4 and UnixWare is not like this; I had to write
code explicitly for UnixWare, Solaris, and AIX to get, among
other things, this type of behaviour.

Here's the comment from Solaris:

 * One file structure is allocated for each open/creat/pipe call.
 * Main use is to hold the read/write pointer associated with
 * each open file.
typedef struct file {

It also credits SVr4 11.28 for file.h itself.

I'm pretty sure Ultrix didn't have this bug, either, and it was
4.3 based.

I think it's an artifact of the way the struct file is used
on a list to create the system open file table in BSD 4.4 based
systems (I checked BSDI; it has the bug).

-- Terry Lambert
-- Whistle Communications, Inc.

To Unsubscribe: send mail to
with "unsubscribe freebsd-current" in the body of the message

Reply via email to