From owner-freebsd-hackers@freebsd.org Sat Dec 30 14:06:19 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 4F508E86D99 for ; Sat, 30 Dec 2017 14:06:19 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2915E7D705; Sat, 30 Dec 2017 14:06:18 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBUE6AM5076012; Sat, 30 Dec 2017 06:06:10 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBUE68qD076011; Sat, 30 Dec 2017 06:06:08 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712301406.vBUE68qD076011@pdx.rh.CN85.dnsmgr.net> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? In-Reply-To: <5A46A638.1060901@grosbein.net> To: Eugene Grosbein Date: Sat, 30 Dec 2017 06:06:08 -0800 (PST) CC: Ian Lepore , Yuri , Freebsd hackers list X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 30 Dec 2017 15:25:55 +0000 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: Sat, 30 Dec 2017 14:06:19 -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. No error on close should be treated as irreleveant, they signify something has gone wrong and itis best to inform the user and let the user decide if this is irrelevant or not. Code that does not test return codes from EVERY single thing that can return an error should be taken out back shown the danish axe, clean it up or get it out of our tree! One should never code to the "normal" conditions situation, it makes for code that does not work well when the "abnormal" conditions arrise. I would argue that in the above sample of "closing and unlinking" it would actually be better to exit if the close failed possibly leaving behind the evidence of why/what failed rather than blindling forging ahead and potentially destroying the evidecnce by unlinking the file. If someone wants to go chasing after "failure to check exit codes" please begin with /etc/rc.d/*, these scripts are so full of it I laugh every time I see a system come up multiuser after 10+ errors have happendend in them. -- Rod Grimes rgrimes@freebsd.org