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.
-- te...@whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
