Date: Sat, 30 Dec 2017 03:31:52 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Ian Lepore <ian@freebsd.org>, Yuri <yuri@rawbw.com>, Freebsd hackers list <freebsd-hackers@FreeBSD.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <5A46A638.1060901@grosbein.net> In-Reply-To: <1514572041.12000.7.camel@freebsd.org> References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A46A638.1060901>