From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 063E21F453 for ; Mon, 29 Apr 2019 20:26:30 +0000 (UTC) Received: from localhost ([127.0.0.1]:34881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLCr5-0005Rc-MX for normalperson@yhbt.net; Mon, 29 Apr 2019 16:26:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLCr1-0005RV-Ai for bug-gnulib@gnu.org; Mon, 29 Apr 2019 16:26:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLCr0-0006ez-Et for bug-gnulib@gnu.org; Mon, 29 Apr 2019 16:26:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42756) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hLCr0-0006d0-8S for bug-gnulib@gnu.org; Mon, 29 Apr 2019 16:26:22 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8FAB88762E for ; Mon, 29 Apr 2019 20:26:15 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-123.ams2.redhat.com [10.36.116.123]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AC3D76B498; Mon, 29 Apr 2019 20:26:14 +0000 (UTC) From: Florian Weimer To: Eric Blake Subject: Re: Why does close_stdout close stdout and stderr? References: <87muk8d295.fsf@oldenburg2.str.redhat.com> Date: Mon, 29 Apr 2019 22:26:12 +0200 In-Reply-To: (Eric Blake's message of "Mon, 29 Apr 2019 14:49:39 -0500") Message-ID: <877ebcd0d7.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 29 Apr 2019 20:26:15 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * Eric Blake: > On 4/29/19 2:45 PM, Florian Weimer wrote: >> I get that error checking is important. But why not just use ferror and >> fflush? Closing the streams is excessive and tends to introduce >> use-after-free issues, as evidenced by the sanitizer workarounds. > > If I recall the explanation, at least some versions of NFS do not > actually flush on fflush(), but wait until close(). If you want to avoid > data loss and ensure that things written made it to the remote storage > while detecting every possible indication when an error may have > prevented that from working, then you have to go all the way through > close(). Any file system on Linux does this to a varying degree (unlike Solaris and Windows, I think). If you want to catch low-level I/O errors, you need to call fsync after fflush. And I doubt this is something we want to do because it will result in bad-looking performance. But the NFS aspect is somewhat plausible at least. I can try to figure out if NFS makes a difference for Linux here, i.e. if there are cases where a write will succeed, but only an immediately following close will report an error condition that is known, in principle, even at the time of the write. A difference between hard and soft NFS mounts could matter in this context. Thanks, Florian