Re: [musl] Re: Tweaking the program name for <err.h> functions

[Rich Felker <dalias@libc.org>]

On Tue, Mar 12, 2024 at 03:31:04PM +0100, Florian Weimer wrote:
> * Zack Weinberg:
> 
> > On Tue, Mar 12, 2024, at 9:54 AM, Florian Weimer wrote:
> >>> Doing this would break many programs, such as:
> >>> - most of coreutils, e.g. programs like ls, cat or head, since they
> >>>   always `close` their input and output descriptors (when they've
> >>>   written or read something) to make sure to diagnose all errors
> >>
> >> A slightly better way to do this is to do fflush (stdout) followed by
> >> error checking on close (dup (fileno (stdout))).
> >
> > Does that actually report delayed write errors?  As you have it,
> > the close() just drops the fd created by the dup(), the OFD is
> > still referenced by fd 1 and therefore remains open.
> 
> I don't think the VFS close action is subject to reference counting.
> Otherwise the current coreutils error checking wouldn't work because in
> many cases, another process retains a reference to the OFD.

It is. close only reports errors if it's the last fd referring to the
ofd. It's an incredibly stupid design choice by NFS that mismatches
expected fd behavior. This is why my alternate proposal for doing it
used dup2 to remove the original reference on fd<3 without closing it,
so that the close of the dup would have a chance to be the last close.
But indeed none of these ways help if some other process still has a
reference.

The right thing to do here IMO has always been to ignore this and let
people who configure their NFS setups not to synchronously report
errors deal with the resulting data loss. (And on a deeper level, the
right thing is not to use NFS, print out the NFS source code and burn
it, etc. :) But if folks insist on trying to handle it more
gracefully, I'm not stopping them.

Rich