On 26/01/2026 13:15, Jan Kara wrote:

On Sun 25-01-26 10:37:01, Zack Weinberg wrote:

quoted

On Sat, Jan 24, 2026, at 4:57 PM, The 8472 wrote:

quoted

quoted

      [QUERY: Do delayed errors ever happen in any of these situations?

         - The fd is not the last reference to the open file description

         - The OFD was opened with O_RDONLY

         - The OFD was opened with O_RDWR but has never actually
           been written to

         - No data has been written to the OFD since the last call to
           fsync() for that OFD

         - No data has been written to the OFD since the last call to
           fdatasync() for that OFD

         If we can give some guidance about when people don’t need to
         worry about delayed errors, it would be helpful.]

In particular, I really hope delayed errors *aren’t* ever reported
when you close a file descriptor that *isn’t* the last reference
to its open file description, because the thread-safe way to close
stdout without losing write errors[2] depends on that not happening.

So I've checked and in Linux ->flush callback for the file is called
whenever you close a file descriptor (regardless whether there are other
file descriptors pointing to the same file description) so it's upto
filesystem implementation what it decides to do and which error it will
return... Checking the implementations e.g. FUSE and NFS *will* return
delayed writeback errors on *first* descriptor close even if there are
other still open descriptors for the description AFAICS.

Regarding the "first", does that mean the errors only get delivered once?
I.e. if a concurrent fork/exec happens for process spawning and the fork-child
closes the file descriptors then this closing may basically receive the errors
and the parent will not see them (unless additional errors happen)?
Or if _any_ part of the program dups the descriptor and then closes it without
reporting errors then all uses of those descriptor must consider error delivery
on close to be unreliable?