From owner-freebsd-hackers@freebsd.org Fri Dec 29 20:32:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6233EAF094 for ; Fri, 29 Dec 2017 20:32:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60F897AA5E; Fri, 29 Dec 2017 20:32:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBTKW05P040144 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Dec 2017 21:32:00 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ian@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vBTKVtHJ096928 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Dec 2017 03:31:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? To: Ian Lepore , Yuri , Freebsd hackers list References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> From: Eugene Grosbein Message-ID: <5A46A638.1060901@grosbein.net> Date: Sat, 30 Dec 2017 03:31:52 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1514572041.12000.7.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 20:32:10 -0000 30.12.2017 1:27, Ian Lepore wrote: > There's really no point in checking on a close from a file opened only > for reading. You can argue it should be checked on a file open for > writing, but often isn't because you're then confronted with the > question "what should/can I do if there is an error?" If you report > the error and exit, then what about other files that were open at the > time? They're going to be closed by the kernel as part of process > cleanup, with no error checking or reporting. > > Also, with the async nature of filesystems, IO errors can still happen > after the close, unless fsync() was used. So if you're going to miss > most of the errors because of that, why bother to check at all? Almost any file opened for writing may occur to reside on NFS or some strange FUSE file system or just on removable storage. As general rule, an application should somehow report any file i/o error including close(), especially when data loss can happen due to unflushed buffers. It may be messages written to syslog or stderr with no error checking here to prevent recursion. For example, a word processing application must warn user in any such case and not remove temporary copy, if any etc. It's up to user whether to utilize such async filesystems that lie about success of close() system call. Properly written application should not excuse itself just because of existence of such file systems. Of course, there are cases when that's irrelevant, f.e. closing temporary file that is no more needed and being unlinked anyway.