/proc/PID/fd/NUM symlinks are quasi-universal on Linux, but they don't exist anywhere else (except on Cygwin which emulates them).
/proc/PID/fd/NUM also exist on AIX and Solaris, but they aren't symlinks. Portably, to get information about open files, install
/proc/PID/fd/NUM is a slightly magic symbolic link to the file that the process with the ID PID has open on the file descriptor NUM. This link is magic in that, for example, it can be used to access the file even if the file is removed. The link will track the file through renames, too.
/proc/self is a magic symbolic link which points to
/proc/PID where PID is the process that accesses the link.
This feature is present on virtually all Linux systems. It's provided by the driver for the proc filesystem, which is technically optional but used for so many things (including making the
ps work — it reads from
/proc/PID) that it's almost never left out even on embedded systems.
Cygwin emulates Linux's
/proc/PID/fd/NUM (for Cygwin processes) and
Solaris (since version 2.6), AIX
/proc/PID/fd entries for each file descriptor, but they appear as the same type as the opened file, so they provide no information about the path of the file. They do however report the same
stat information as
fstat would report to the process that has the file open, so it's possible to determine on which filesystem the file is located and its inode number. Directories appear as symbolic links, however they are magic symlinks which can only be followed, and
readlink returns an empty string.
Under AIX, the
procfiles command displays some information about a process's open files. Under Solaris, the
pfiles command displays some information about a process's open files. This does not include the path to the file (on Solaris, it does since Solaris 10, see below).
In addition to
/proc/PID/fd/NUM, modern Solaris versions have
/proc/PID/path/NUM which contains symbolic links similar to Linux's symlinks in
pfiles command shows information about a process's open files, including paths.
/proc/PID/fd is a text file which contains one record (line) per file descriptor opened by the process. The file name is not tracked there.
/proc/PID/ is a directory, but it doesn't contain any information about file descriptors.
/proc but no direct access to file descriptors
(Note: sometimes it's possible to obtain information about a process's open files by riffling through its memory image which is accessible under
/proc. I don't count that as “direct access”.)
/proc/PID is a file
The proc filesystem itself started out in UNIX 8th edition, but with a different structure, and went through Plan 9 and back to some unices. I think that all operating systems with a
/proc have an entry for each PID, but on many systems, it's a regular file, not a directory. The following systems have a
/proc/PID which needs to be read with
- Solaris up to 2.5
- OSF/1 now known as Tru64
- IRIX (?)
- SCO (?)
MINIX 3 has a procfs server which provides several Linux-like components including
/proc/PID/ directories. However this does not there is no
/proc/PID/ directories, but they do not provide information about open file descriptors. (There is however
/proc/PID/file which is similar to Linux's
/proc/PID/exe, giving access to the executable through a symbolic link.)
FreeBSD's procfs is deprecated.
- Mac OS X
File descriptor information through other channels
fuser command lists the processes that have a specified file open, or a file open on the specified mount point. This command is standard (available on all XSI-compliant systems, i.e. POSIX with the X/Open System Interface Extension).
You can't go from a process to file names with this utility.
Lsof stands for “list open files”. It is a third-party tool, available (but usually not part of the default installation) for most unix variants. Obtaining information about open files is very system-dependent, as the analysis above might have made you suspect. The lsof maintainer has done the work of combining it all under a single interface.
You can read the FAQ to see what kinds of difficulties lsof has to put up with. On most unices, obtaining information about the names of open files requires parsing kernel data structures. Quoting from FAQ 3.3 “Why doesn't lsof report full path names?”:
Lsof can't obtain path name components from the kernel name caches of the following dialects:
Only the Linux kernel records full path names in the structures it maintains about open files; instead, most kernels convert path names to device and node number doublets and use them for subsequent file references once files have been opened.
If you need to parse information from
lsof's output, be sure to use the
-F mode (one field per line), preferably the
-F0 mode (null-delimited fields). To get information about a specific file descriptor of a specific process, use the
-a option with
-p PID and
-d NUM, e.g.
lsof -a -p 123 -d 0 -F0n.
/dev/fd/NUM for file descriptors of the current process
Many unix variants provide a way to for a process to access its open files via a file name: opening
/dev/fd/NUM is equivalent to calling
dup(NUM). These names are useful when a program wants a file name but you want to pass an already-open file (e.g. a pipe or socket); for example the shells that implement process substitution use them where available (using a temporary named pipe where
/dev/fd is unavailable).
/dev/fd exists, there are also usually (always?) synonyms (sometimes symbolic links, sometimes hard links, sometimes magic files with equivalent properties)
- Under Linux,
/dev/fd is a symbolic link to
- Under most unices (IRIX, OpenBSD, NetBSD, SCO, Solaris, …), the entries in
/dev/fd are character devices. They usually appear whether the file descriptor is open or not, and entries may not be available for file descriptors above a certain number.
- Under FreeBSD and OSX, the fdescfs filesystem provides a dynamic
/dev/fd directory which follows the open descriptors of the calling process. A static
/dev/fd is available is
/dev/fd is not mounted.
- Under OSF/1 (Tru64),
/dev/fd is provided via fdfs.
- There is no
/dev/fd on AIX or HP-UX.