A close system call is a system call used to close a file descriptor by the kernel. For most file systems, a program terminates access to a file in a filesystem using the close system call. This flushes file buffers, updates file metadata, which may include and end-of-file indicator in the data; de-allocates resources associated with the file (including the file descriptor) and updates the system wide table of files in use. Some programming languages maintain a data structure of files opened by their runtime library and may close when the program terminates. This practice is known as resource acquisition is initialization (RAII). Some operating systems will invoke <code>close</code> on files held by a program if it terminates. Some operating systems will invoke the <code>close</code> syscall as part of an operating system recovery as a result of a system failure.
The C standard library provides the <code>fclose</code> function with the signature
The file is represented by the file pointer <code>stream</code>, which is typically an abstraction over a platform-dependent handle to the underlying file object. As such, <code>fclose</code> is almost always implemented as a library call which in turn closes the file with the corresponding system call. This additional layer of abstraction allows the function to remain portable across different environments while providing the same functionality. A successful call to <code>fclose</code> returns zero, but if an error occurs the function instead returns <code>EOF</code> (commonly defined as -1). In both cases, the file pointer is guaranteed to be disassociated from the file and should not be further used by an application.
The POSIX standard includes the <code>close</code> system call, declared as
The function takes the file descriptor <code>fildes</code>, an integer identifier for the open file, as a parameter. It allows the value of <code>fildes</code> to be reused for later opened files, and if no other file descriptor currently refers to the same file, any resources associated with the open file are freed. On success, <code>close</code> returns zero. Otherwise if an error occurs, the function returns -1 and assigns a relevant error code to the global variable <code>errno</code>. In this situation, the value of <code>errno</code> and the state of <code>fildes</code> are partially dependent on the version of POSIX the system adheres to.
In all versions of POSIX, <code>errno</code> is set to <code>EBADF</code> if <code>fildes</code> is an invalid file descriptor. And from POSIX.1-2001 onwards, to <code>EIO</code> if a platform-dependent IO error occurs. Up to and including POSIX.1-2017, if a signal is sent to the process and interrupts the call to <code>close</code>, the call fails with <code>EINTR</code> and the state of the file descriptor is explicitly unspecified by the standard. So depending on the implementation, the file descriptor may have been closed, in which case <code>close</code> should not be called again. Or the file descriptor may still remain open, meaning <code>close</code> should be called again.
This behaviour was argued by developers to be unsafe for portable applications. In particular, it can cause race conditions in multithreaded environments, where a file descriptor may be reused in a different thread prior to retrying <code>close</code>. To address this, POSIX.1-2024 instead requires that in the event of an interrupted call to <code>close</code>, the function can either succeed, fail with <code>EINTR</code> and leave the file descriptor open, or fail with <code>EINPROGRESS</code> and close the file descriptor.