Movatterモバイル変換

CLOSE(2)                   Linux Programmer's ManualCLOSE(2)NAME       close - close a file descriptorSYNOPSIS       #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 (seefcntl(2))  held  on  the       file it was associated with, and owned by the process, are removed (re-       gardless 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  (seeopen(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 usingunlink(2), the file is deleted.RETURN VALUE       close()  returns  zero on success.  On error, -1 is returned, and errno       is set appropriately.ERRORS       EBADF  fd isn't a valid open file descriptor.       EINTR  The close() call was interrupted by a signal; seesignal(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 subsequentwrite(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.NOTES       A  successful  close does not guarantee that the data has been success-       fully 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, usefsync(2).  (It will depend on the disk hard-       ware at this point.)       The close-on-exec file descriptor flag can be used  to  ensure  that  a       file  descriptor  is  automatically closed upon a successfulexecve(2);       seefcntl(2) for details.       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.   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 previouswrite(2) operation are  re-       ported  only  on the final close() that releases the open file descrip-       tion.  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 in-       valid) 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  stan-       dard.       A  careful  programmer  who  wants to know about I/O errors may precede       close() with a call tofsync(2).       The EINTR error is a somewhat special case.  Regarding the EINTR error,       POSIX.1-2013 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 implemen-       tations, where, as with other errors that may be reported  by  close(),       the  file descriptor is guaranteed to be closed.  However, it also per-       mits another possibility: that the implementation returns an EINTR  er-       ror  and  keeps the file descriptor open.  (According to its documenta-       tion, 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 ALSOfcntl(2),fsync(2),open(2),shutdown(2),unlink(2),fclose(3)COLOPHON       This page is part of release 5.05 of the Linux  man-pages  project.   A       description  of  the project, information about reporting bugs, and the       latest    version    of    this    page,    can     be     found     at       https://www.kernel.org/doc/man-pages/.Linux                             2019-10-10CLOSE(2)