From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id DB99F295D9 for ; Tue, 12 Mar 2024 15:42:21 +0100 (CET) Received: (qmail 3941 invoked by uid 550); 12 Mar 2024 14:38:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3918 invoked from network); 12 Mar 2024 14:38:08 -0000 Date: Tue, 12 Mar 2024 10:42:26 -0400 From: Rich Felker To: Florian Weimer Cc: Zack Weinberg , Gabriel Ravier , "Skyler Ferrante (RIT Student)" , musl@lists.openwall.com, Andreas Schwab , Alejandro Colomar , Thorsten Glaser , NRK , Guillem Jover , GNU libc development , libbsd@lists.freedesktop.org, "Serge E. Hallyn" , Iker Pedrosa , Christian Brauner Message-ID: <20240312144225.GC4163@brightrain.aerifal.cx> References: <20240311194756.GY4163@brightrain.aerifal.cx> <40962405-c5b4-4925-9ca5-7a1c723ebbfd@gmail.com> <875xxrv9mm.fsf@oldenburg.str.redhat.com> <84bf19d7-c2ba-46e7-a77d-ecc6497f08a1@app.fastmail.com> <87o7bjttcn.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o7bjttcn.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: Tweaking the program name for 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