GENWiki

CLOSE(2) Linux Programmer's Manual CLOSE(2)

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 appropriately.

ERRORS

     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(2).

     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, use fsync(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 successful execve(2);
     see fcntl(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  previous  write(2)  operation  are
     reported 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
     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  stan-
     dard

     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-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
     error 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.