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
