Re: Why does close_stdout close stdout and stderr?

[Bruno Haible]

Paul Eggert wrote:
> A better fix ... would be to write a better module (we could call it 
> "flushout", say) that would define a function ("flushout_stream", say) 
> that would act like fflush but would do a better job with NFS-based 
> streams by playing the dup+close+fsync trick. We could then modify 
> coreutils etc. to use this new module instead of the old one. The hard 
> part is the "modify coreutils etc." part, because flushout_stream will 
> be less convenient to use than the current API.

I disagree that it would be a better module.

1) As stated in [1], I think that it would be wrong for gnulib to call
   fsync().

2) It would be a hacky module that makes assumptions about how the kernel
   behaves, assumptions that go further than what POSIX guarantees:

   - Do you want to apply the dup+close trick [2] for all file descriptors
     or only for those that write to certain file systems? In the first case,
     you are causing all coreutils programs to make more system calls than
     needed. In the second case, you are making assumptions about the file
     systems. We know about NFS and Coda only through code inspection of
     the Linux kernel.

   - The dup+close trick may work on some kernels and not on others.
     It is perfectly reasonable for a kernel to delay flushing the internal
     buffers associated with a file until the *last* close(). POSIX [3]
     specifies several behaviours of close() that occur only on the last
     close(): "... the last close() shall ...". So a kernel must already
     have the reference-counting needed to detect the last close().
     How do you want to achieve portability from Linux over OpenBSD to Solaris,
     then?

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00039.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00046.html
[3] https://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html