Vegard: fix line wrapping

2019-12-18T06:48:56Z

fix line wrapping

Vegard: new page

2019-12-18T06:47:42Z

new page

New page

<tt>close()</tt> is notoriously difficult to get right. You are supposed to check the return value, but not really handle it (other than printing a diagnostic). If you are wrapping a file descriptor using RAII, then you may not be able to throw an exception or return an error if you are calling <tt>close()</tt> from the destructor.

From the [https://github.com/mkerrisk/man-pages/blob/5373f62f1e4352e665c24dfe49b7e3fe03721cab/man2/close.2#L134 current Linux man page]:
<blockquote>
A careful programmer will check the return value of <tt>close()</tt>, since it is quite possi‐
ble that errors on a previous <tt>write(2)</tt> operation are reported only on the final
<tt>close()</tt> that releases the open file description. Failing to check the return value
when closing a file may lead to silent loss of data. This can especially be observed
with NFS and with disk quota.

Note, however, that a failure return should be used only for diagnostic purposes
(i.e., a warning to the application that there may still be I/O pending or there may
have been failed I/O) or remedial purposes (e.g., writing the file once more or cre‐
ating a backup).

Retrying the <tt>close()</tt> after a failure return is the wrong thing to do, since this may
cause a reused file descriptor from another thread to be closed. This can occur
because the Linux kernel always releases the file descriptor early in the close oper‐
ation, freeing it for reuse; the steps that may return an error, such as flushing
data to the filesystem or device, occur only later in the close operation.

Many other implementations similarly always close the file descriptor (except in the
case of <tt>EBADF</tt>, meaning that the file descriptor was invalid) even if they subse‐
quently report an error on return from <tt>close()</tt>. POSIX.1 is currently silent on this
point, but there are plans to mandate this behavior in the next major release of the
standard

A careful programmer who wants to know about I/O errors may precede <tt>close()</tt> with a
call to <tt>fsync(2)</tt>.
</blockquote>

Thus, best practice would seem to be:
* Call <tt>fsync()</tt> at some point after writing data, but before <tt>close()</tt>; this should report any I/O errors
* Only use <tt>close()</tt> to actually destroy the file descriptor when the file descriptor is no longer in use
* On Linux, the file descriptor is always closed regardless of the return value (and should therefore not be retried); on other systems, <tt>EINTR</tt> may signal that the file descriptor was ''not'' closed



[[Category:Programming]]
[[Category:C]]

← Older revision		Revision as of 06:48, 18 December 2019
Line 3:		Line 3:
	From the [https://github.com/mkerrisk/man-pages/blob/5373f62f1e4352e665c24dfe49b7e3fe03721cab/man2/close.2#L134 current Linux man page]:		From the [https://github.com/mkerrisk/man-pages/blob/5373f62f1e4352e665c24dfe49b7e3fe03721cab/man2/close.2#L134 current Linux man page]:
	<blockquote>		<blockquote>
	A careful programmer will check the return value of <tt>close()</tt>, since it is quite ~~possi‐~~		A careful programmer will check the return value of <tt>close()</tt>, since it is quite possible
	~~ble~~ that errors on a previous <tt>write(2)</tt> operation are reported only on the final		that errors on a previous <tt>write(2)</tt> operation are reported only on the final
	<tt>close()</tt> that releases the open file description. Failing to check the return value		<tt>close()</tt> that releases the open file description. Failing to check the return value
	when closing a file may lead to silent loss of data. This can especially be observed		when closing a file may lead to silent loss of data. This can especially be observed
Line 11:		Line 11:
	Note, however, that a failure return should be used only for diagnostic purposes		Note, however, that a failure return should be used only for diagnostic purposes
	(i.e., a warning to the application that there may still be I/O pending or there may		(i.e., a warning to the application that there may still be I/O pending or there may
	have been failed I/O) or remedial purposes (e.g., writing the file once more or ~~cre‐~~		have been failed I/O) or remedial purposes (e.g., writing the file once more or creating
	~~ating~~ a backup).		a backup).

	Retrying the <tt>close()</tt> after a failure return is the wrong thing to do, since this may		Retrying the <tt>close()</tt> after a failure return is the wrong thing to do, since this may
	cause a reused file descriptor from another thread to be closed. This can occur		cause a reused file descriptor from another thread to be closed. This can occur
	because the Linux kernel always releases the file descriptor early in the close ~~oper‐~~		because the Linux kernel always releases the file descriptor early in the close operation,
	~~ation,~~ freeing it for reuse; the steps that may return an error, such as flushing		freeing it for reuse; the steps that may return an error, such as flushing
	data to the filesystem or device, occur only later in the close operation.		data to the filesystem or device, occur only later in the close operation.

	Many other implementations similarly always close the file descriptor (except in the		Many other implementations similarly always close the file descriptor (except in the
	case of <tt>EBADF</tt>, meaning that the file descriptor was invalid) even if they ~~subse‐~~		case of <tt>EBADF</tt>, meaning that the file descriptor was invalid) even if they subsequently
	~~quently~~ report an error on return from <tt>close()</tt>. POSIX.1 is currently silent on this		report an error on return from <tt>close()</tt>. POSIX.1 is currently silent on this
	point, but there are plans to mandate this behavior in the next major release of the		point, but there are plans to mandate this behavior in the next major release of the
	standard		standard

close() - Revision history

Vegard: fix line wrapping

Vegard: new page