> If it's a redirected output file you simply make it O_APPEND, at which
> point the seek offset in the descriptor becomes irrelevant.
As others have pointed out, O_APPEND is much newer than the
offset-sharing behavior.
It also doesn't fix things for inputs. Of course with buffering, it
At 5:00 pm -0700 6/4/99, John Polstra wrote:
>[...]
>But O_APPEND didn't exist in early versions of Unix. I'm sure it
>wasn't present in V6, and I'm pretty sure it wasn't present in V7
>either.
[Blows dust off V7 manual]
You're right: it wasn't.
--
Bob Bishop (0118) 977 4017 inte
In article <199904061701.kaa09...@apollo.backplane.com>,
Matthew Dillon wrote:
> :
> :It's not necessarily breakage. Not having any mechanism other than
> :open to get your own seek offset is nasty, but sharing a seek offset
> :can also be useful. File descriptors can't be "reverse-inherited",
:
:
:Matthew Dillon writes:
:
:> 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.
:
:It's not necessarily breakage. Not having any mechanism other than
:open to get your ow
Matthew Dillon writes:
> 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.
It's not necessarily breakage. Not having any mechanism other than
open to get your own seek offse
:> 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 ha
On Mon, 5 Apr 1999, Terry Lambert wrote:
> 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
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. A
:
: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
descrip
On Mon, 5 Apr 1999, Terry Lambert wrote:
> > What I would like to do is have a child process read
> > from an inherited file descriptor without affecting the
> > parent process's access to the descriptor (for example,
> > the offset it reads from using a normal read() or readv()).
>
> This should
Robert Watson wrote:
>
> Terry,
>
> In the BUGS section of the 4.0-CURRENT aio_read man page,
> the following comment is made:
>
> The value of iocb->aio_offset is ignored.
>
> Is this actually the case, and what would be required to
> fix it? Does this comment imply that reads always
:Terry,
:
:In the BUGS section of the 4.0-CURRENT aio_read man page, the following
:comment is made:
:
: The value of iocb->aio_offset is ignored.
:
:Is this actually the case, and what would be required to fix it? Does
:this comment imply that reads always occur at the current file offset f
Brian Dean said:
>
> I'm using a dual 350MHz Dell Precision 410 with 4.0-19990130-SNAP (SMP
> enabled) to prototype a program that uses asynchronous read and write
> (aio_read() and aio_write()), and found that the following simple and
> not very useful program (it's for demonstration purposes onl
13 matches
Mail list logo
