закрыть дескриптор файла (close a file descriptor)
Имя (Name)
close - close a file descriptor
Синопсис (Synopsis)
#include <unistd.h>
int close(int fd);
Описание (Description)
close() closes a file descriptor, so that it no longer refers to
any file and may be reused. Any record locks (see fcntl(2)) held
on the file it was associated with, and owned by the process, are
removed (regardless of the file descriptor that was used to
obtain the lock).
If fd is the last file descriptor referring to the underlying
open file description (see open(2)), the resources associated
with the open file description are freed; if the file descriptor
was the last reference to a file which has been removed using
unlink(2), the file is deleted.
Возвращаемое значение (Return value)
close() returns zero on success. On error, -1 is returned, and
errno is set to indicate the error.
Ошибки (Error)
EBADF fd isn't a valid open file descriptor.
EINTR The close() call was interrupted by a signal; see
signal(7).
EIO An I/O error occurred.
ENOSPC, EDQUOT
On NFS, these errors are not normally reported against the
first write which exceeds the available storage space, but
instead against a subsequent write(2), fsync(2), or
close().
See NOTES for a discussion of why close() should not be retried
after an error.
Стандарты (Conforming to)
POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
Примечание (Note)
A successful close does not guarantee that the data has been
successfully saved to disk, as the kernel uses the buffer cache
to defer writes. Typically, filesystems do not flush buffers
when a file is closed. If you need to be sure that the data is
physically stored on the underlying disk, use fsync(2). (It will
depend on the disk hardware at this point.)
The close-on-exec file descriptor flag can be used to ensure that
a file descriptor is automatically closed upon a successful
execve(2); see fcntl(2) for details.
Multithreaded processes and close()
It is probably unwise to close file descriptors while they may be
in use by system calls in other threads in the same process.
Since a file descriptor may be reused, there are some obscure
race conditions that may cause unintended side effects.
Furthermore, consider the following scenario where two threads
are performing operations on the same file descriptor:
1. One thread is blocked in an I/O system call on the file
descriptor. For example, it is trying to write(2) to a pipe
that is already full, or trying to read(2) from a stream
socket which currently has no available data.
2. Another thread closes the file descriptor.
The behavior in this situation varies across systems. On some
systems, when the file descriptor is closed, the blocking system
call returns immediately with an error.
On Linux (and possibly some other systems), the behavior is
different: the blocking I/O system call holds a reference to the
underlying open file description, and this reference keeps the
description open until the I/O system call completes. (See
open(2) for a discussion of open file descriptions.) Thus, the
blocking system call in the first thread may successfully
complete after the close() in the second thread.
Dealing with error returns from close()
A careful programmer will check the return value of close(),
since it is quite possible that errors on a previous write(2)
operation are reported only on the final close() 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
creating a backup).
Retrying the close() 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 operation,
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 EBADF, meaning that the file
descriptor was invalid) even if they subsequently report an error
on return from close(). 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 close() with a call to fsync(2).
The EINTR error is a somewhat special case. Regarding the EINTR
error, POSIX.1-2008 says:
If close() is interrupted by a signal that is to be
caught, it shall return -1 with errno set to EINTR and the
state of fildes is unspecified.
This permits the behavior that occurs on Linux and many other
implementations, where, as with other errors that may be reported
by close(), the file descriptor is guaranteed to be closed.
However, it also permits another possibility: that the
implementation returns an EINTR error and keeps the file
descriptor open. (According to its documentation, HP-UX's
close() does this.) The caller must then once more use close()
to close the file descriptor, to avoid file descriptor leaks.
This divergence in implementation behaviors provides a difficult
hurdle for portable applications, since on many implementations,
close() must not be called again after an EINTR error, and on at
least one, close() must be called again. There are plans to
address this conundrum for the next major release of the POSIX.1
standard.
Смотри также (See also)
close_range(2), fcntl(2), fsync(2), open(2), shutdown(2),
unlink(2), fclose(3)
