Re: Request clarification about dup2 system call

[Andreas Gruenbacher]

Hi,

On Monday 30 September 2002 15:35, Chet Ramey wrote:
> > Hello,
> >
> > I have been running into a bug in which a write failure was not correctly
> > reported. The system call sequence was something like this:
> >
> >     fd = fileno(stdout);
> >     fd2 = open(...);
> >     ...
> >     write(fd2, ...);
> >     /* fsync(fd2) or close(fd2) would return an error here */
> >     if (dup2(fd, fd2) < 0)
> >             /* error */
>
> Since you sent this to bug-bash, where in bash are you seeing this
> behavior?

It happens if a command like `echo blah >> file' results in errors that are
only reported when `file' is closed. In that case the error is silently
ignored. This is part of the syslog that I got (actually, Werner Fink
<werner@suse.de> produced the log):

  25549 open("f", O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0666) = 4
  25549 fcntl64(1, F_GETFD) = 0
  25549 fcntl64(1, F_DUPFD, 10) = 10
  25549 fcntl64(1, F_GETFD) = 0
  25549 fcntl64(10, F_SETFD, FD_CLOEXEC) = 0
  25549 dup2(4, 1) = 1
  25549 close(4) = 0
  25549 write(1, "hugo\n", 5) = 5
  25549 dup2(10, 1) = 1
  25549 fcntl64(10, F_GETFD) = 0x1 (flags FD_CLOEXEC)
  25549 close(10) = 0

The write goes to a buffer but the buffer later cannot be flushed; the bug is
that the following dup2 eats the error code. I had this particular problem on
an NFS mounted file system in a particularly nasty setup, but the setup and
error can be reproduced.

Is this a known issue?


--Andreas.