 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "File descriptor" – news ·newspapers ·books ·scholar ·JSTOR(September 2025) (Learn how and when to remove this message) |
InUnix andUnix-likecomputeroperating systems, afile descriptor (FD, less frequentlyfildes) is a process-unique identifier (handle) for afile or otherinput/outputresource, such as apipe ornetwork socket.
File descriptors typically have non-negativeinteger values, with negative values being reserved to indicate "no value" or error conditions.
File descriptors are a part of thePOSIXAPI. Each Unixprocess (except perhapsdaemons) should have three standard POSIX file descriptors, corresponding to the threestandard streams:
| Integer value | Name | <unistd.h> symbolic constant[1] | <stdio.h> file stream[2] |
|---|---|---|---|
| 0 | Standard input | STDIN_FILENO | stdin |
| 1 | Standard output | STDOUT_FILENO | stdout |
| 2 | Standard error | STDERR_FILENO | stderr |
In the traditional implementation of Unix, file descriptors index into a per-processfile descriptor table maintained by the kernel, that in turn indexes into a system-wide table of files opened by all processes, called thefile table. This table records themode with which the file (or other resource) has been opened: for reading, writing, appending, and possibly other modes. It also indexes into a third table called theinode table that describes the actual underlying files.[3] To perform input or output, the process passes the file descriptor to the kernel through asystem call, and the kernel will access the file on behalf of the process. The process does not have direct access to the file or inode tables.
OnLinux, the set of file descriptors open in a process can be accessed under the path/proc/PID/fd/, where PID is theprocess identifier. File descriptor/proc/PID/fd/0 isstdin,/proc/PID/fd/1 isstdout, and/proc/PID/fd/2 isstderr. As a shortcut to these, any running process can also accessits own file descriptors through the folders/proc/self/fd and/dev/fd.[4]
InUnix-like systems, file descriptors can refer to anyUnix file type named in a file system. As well as regular files, this includesdirectories,block andcharacter devices (also called "special files"),Unix domain sockets, andnamed pipes. File descriptors can also refer to other objects that do not normally exist in the file system, such asanonymous pipes andnetwork sockets.
TheFILE data structure in theC standard I/O library usually includes a low level file descriptor for the object in question on Unix-like systems. The overall data structure provides additional abstraction and is instead known as afilehandle.
The following lists typical operations on file descriptors on modernUnix-like systems. Most of these functions are declared in the<unistd.h> header, but some are in the<fcntl.h> header instead.
Thefcntl() function is used to perform various operations on a file descriptor, depending on the command argument passed to it. There are commands to get and set attributes associated with a file descriptor, includingF_GETFD, F_SETFD, F_GETFL andF_SETFL.
at suffix operationsA series of new operations has been added to many modern Unix-like systems, as well as numerous C libraries, to be standardized in a future version ofPOSIX.[7] Theat suffix signifies that the function takes an additional first argument supplying a file descriptor from whichrelative paths are resolved, the forms lacking theat suffix thus becoming equivalent to passing a file descriptor corresponding to the currentworking directory. The purpose of these new operations is to defend against a certain class ofTOCTOU attacks.
Unix file descriptors behave in many ways ascapabilities. They can be passed between processes acrossUnix domain sockets using thesendmsg() system call. Note, however, that what is actually passed is a reference to an "open file description" that has mutable state (the file offset, and the file status and access flags). This complicates the secure use of file descriptors as capabilities, since when programs share access to the same open file description, they can interfere with each other's use of it by changing its offset or whether it is blocking or non-blocking, for example.[8][9] In operating systems that are specifically designed as capability systems, there is very rarely any mutable state associated with a capability itself.
A Unix process' file descriptor table is an example of aC-list.