[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Mar 2024 10:42:26 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Zack Weinberg <zack@...folio.org>, Gabriel Ravier <gabravier@...il.com>,
"Skyler Ferrante (RIT Student)" <sjf5462@....edu>,
musl@...ts.openwall.com, Andreas Schwab <schwab@...e.de>,
Alejandro Colomar <alx@...nel.org>, Thorsten Glaser <tg@...bsd.de>,
NRK <nrk@...root.org>, Guillem Jover <guillem@...rons.org>,
GNU libc development <libc-alpha@...rceware.org>,
libbsd@...ts.freedesktop.org, "Serge E. Hallyn" <serge@...lyn.com>,
Iker Pedrosa <ipedrosa@...hat.com>,
Christian Brauner <christian@...uner.io>
Subject: Re: Re: Tweaking the program name for <err.h> functions
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
