File descriptor

The file descriptors for input, output, and error

In computer programming, a file descriptor is an abstract indicator for accessing a file. The term is generally used in POSIX operating systems. In Microsoft Windows terminology and in the context of the C standard I/O library, "file handle" is preferred, though the latter case is technically a different object (see below).

In POSIX, a file descriptor is an integer, specifically of the C type int. There are 3 standard POSIX file descriptors which presumably every process (save perhaps a daemon) should expect to have:

Integer value	Name
0	Standard Input (stdin)
1	Standard Output (stdout)
2	Standard Error (stderr)

Generally, a file descriptor is an index for an entry in a kernel-resident data structure containing the details of all open files. In POSIX this data structure is called a file descriptor table, and each process has its own file descriptor table. The user application passes the abstract key to the kernel through a system call, and the kernel will access the file on behalf of the application, based on the key. The application itself cannot read or write the file descriptor table directly.

In Unix-like systems, file descriptors can refer to files, directories, block or character devices (also called "special files"), sockets, FIFOs (also called named pipes), or unnamed pipes.

The FILE * file handle in the C standard I/O library routines is technically a pointer to a data structure managed by those library routines; one of those structures usually includes an actual low level file descriptor for the object in question on Unix-like systems. Since file handle refers to this additional layer, it is not interchangeable with file descriptor.

To further complicate terminology, Microsoft Windows also uses the term file handle to refer to the more low-level construct, akin to POSIX's file descriptors. Microsoft's C libraries also provide compatibility functions which "wrap" these native handles to support the POSIX-like convention of integer file descriptors as detailed above.

Operations on file descriptors

Modern Unix-like systems typically provide the following operations on file descriptors:

Creating file descriptors

• open(), open64(), creat(), creat64()
• socket()
• socketpair()
• pipe()

Deriving file descriptors

• dirfd()
• fileno()

Operations on a single file descriptor

• read(), write()
• readv(), writev()
• pread(), pwrite()
• recv(), send()
• recvmsg(), sendmsg() (including allowing sending FDs)
• sendfile()
• lseek(), lseek64()
• fstat(), fstat64()
• fchmod()
• fchown()
• fdopen()
• gzdopen()
• ftruncate()
• fsync()
• fdatasync()
• fstatvfs()

Operations on multiple file descriptors

• select(), pselect()
• poll(), epoll()
• kqueue()

Operations on the file descriptor table

• close()
• dup() (duplicates an existing file descriptor guaranteeing to be the lowest number available file descriptor)
• dup2() (the new file descriptor will have the value passed as an argument)
• fcntl (F_DUPFD)
• fcntl (F_GETFD and F_SETFD)

Operations that modify process state

• fchdir() (sets the process's current working directory based on a directory file descriptor)
• mmap() (maps ranges of a file into the process's address space)

File locking

• flock()
• fcntl (F_GETLK, F_SETLK and F_SETLKW)
• lockf()

Sockets

• connect()
• bind()
• listen()
• accept() (creates a new file descriptor for an incoming connection)
• getsockname()
• getpeername()
• getsockopt()
• setsockopt()
• shutdown() (shuts down one or both halves of a full duplex connection)

Miscellaneous

• ioctl() (a large collection of miscellaneous operations on a single file descriptor, often associated with a device)

Upcoming operations

A series of new operations on file descriptors has been added to many modern Unix-like systems, as well as numerous C libraries, to be standardized in a future version of POSIX. The at suffix signifies that the function takes an additional first argument supplying a file descriptor from which relative paths are resolved, the forms lacking the at suffix thus becoming equivalent to passing a file descriptor corresponding to the current working directory. The purpose of these new operations is to defend against a certain class of TOCTTOU attacks.

• openat()
• faccessat()
• fchmodat()
• fchownat()
• fstatat()
• futimesat()
• linkat()
• mkdirat()
• mknodat()
• readlinkat()
• renameat()
• symlinkat()
• unlinkat()
• mkfifoat()
• fdopendir()

The Native API of the Windows NT family of operating systems also allows callers to specify a root directory when they open a file or other object by name.

File descriptors as capabilities

Unix file descriptors behave in many ways as capabilities. They can be passed between processes across Unix domain sockets using the sendmsg() 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.[1][2] 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 a C-list.

See also

• lsof - a utility that displays information about open file descriptors.