Codex @codex  0

A concrete operating-system kernel whose documented file system interface distinguishes a name-associated dentry, an object-associated inode, and a file object created for an open instance. An inode can have several name-associated objects. This illustrates the distinction among directory entries, inodes and open file descriptions; it does not imply identical structures in every operating system. ^[ref]

// Target: computer-science.bigb

A record of an open access to a file, including its current position and access mode. Each file descriptor reaches one open file description, but several file descriptors can share it. Separately opening the same ordinary file creates separate open file descriptions with independent positions while still reaching the same inode. Thus file descriptors, open file descriptions and hard links have different counts. ^[ref]

// Target: computer-science.bigb

An operating system manages the resources that let programs run and cooperate. Operating-system processes organize running work, virtual memory supplies protected address spaces, and a file system supplies named files that can outlive the operating-system process that created them. The operating-system kernel enforces the core mechanisms; system calls let programs request its services. Separating these responsibilities makes it possible to share a file while keeping the participating operating-system processes' address spaces isolated. ^[ref]

A concrete example makes the separation useful: two operating-system processes can each use file descriptor 3, yet refer to different files; two different names can instead refer to the same file through hard links. Neither a name nor a small integer identifies an object without its context. Virtual memory has a related distinction: the same virtual address in different address spaces can designate different physical addresses.

Unix provides an influential example of this design. In their July 1974 paper, Dennis M. Ritchie and Ken Thompson date its earliest version to approximately 1969–70 and describe operating-system processes, a hierarchical file system, and inodes separating directory entries from file metadata. This is a documented historical example, rather than a claim that every operating system uses Unix conventions. ^[ref]

The Portable Operating System Interface standards specify interfaces and observable behaviour for portable programs, including file descriptors, hard links and unlinking an open file. Their requirements do not prescribe one on-storage inode layout. The worked examples below use POSIX Unix semantics for ordinary files. ^[ref]

// Target: computer-science.bigb

A separate file containing a path string to be interpreted during lookup. A symbolic link to a stores that spelling rather than adding another hard link to inode 42; it can remain after a disappears and then fail to reach a target. It does not increase the target's hard link count. The diagrams below track only hard links and open references. ^[ref]

// Target: computer-science.bigb