Distinguish descriptors from shared open-file state

A process uses a file descriptor as an index into its descriptor table. That table entry references an open file description, represented in Linux by a struct file, which in turn connects to the appropriate underlying object and operations. The underlying object might be a regular file, pipe, socket, or something else. For a seekable regular file, the open file description holds the current offset and file status flags. A pathname is a means of locating an object during open; it is not the lasting identity of every subsequent I/O operation. Renaming or unlinking a name does not simply redirect an already open reference to whatever later appears at that name.

Each ordinary successful open creates a new open file description, even when another open names the same underlying file. Dup creates a new descriptor referring to an existing description instead. Therefore, descriptor equality and object identity answer different questions: different integers can alias one description, and the same integer in two processes need not identify the same object. An integer can also be reused after close. When investigating a stale descriptor bug, track ownership and lifetime rather than assuming that seeing descriptor seven twice proves continuity. The reference diagram should show table entries separately from the descriptions they reference, with offset and status state attached to the latter.

After dup, the descriptors share an offset and file status flags because both reference one open file description. Fork copies the parent’s descriptor entries into the child, with corresponding entries still referencing the same descriptions. A read in the child can consequently change the position used by a later parent read. This sharing does not mean their descriptor tables are one table: closing the child’s entry does not close the parent’s entry. Ordinary threads in one process normally share the descriptor table, which makes a concurrent close and numeric reuse especially dangerous for code that assumes an integer remains associated with its original resource.

Keep file descriptor flags separate from file status flags. FD_CLOEXEC belongs to one descriptor entry; an ordinary dup does not copy it as an enabled flag on the duplicate. Status flags such as O_APPEND or O_NONBLOCK belong to the shared description, so a supported change through one alias affects the other aliases. Some status properties are not changeable with F_SETFL; consult the actual interface instead of treating it as an arbitrary bit assignment. Set close-on-exec atomically when creating or duplicating a descriptor if another thread may exec concurrently. Opening first and setting FD_CLOEXEC later creates an avoidable inheritance race between those two operations.

If workers should read independent regions, a seek followed by a read is not one indivisible positional operation merely because those calls appear next to each other in source. Another user of the shared description can change its offset between them. On a seekable file, pread supplies an explicit byte offset without modifying the shared current offset. It solves the implicit-position race for that operation, but it does not freeze file contents, guarantee a full-length read, or create a transaction with a concurrent writer. Check the returned byte count and define what concurrent mutation means for your application. Opening separately can provide independent offsets while still leaving shared file-content concerns.

Resource cleanup needs the same object-level reasoning. Closing one descriptor removes that reference; aliases can keep the description alive. A child that inherits an unwanted pipe end can prevent another process from observing the expected end-of-file condition even after the intended writer closes its own end. Build a deliberate inheritance list for a launched program, close unused ends on each side, and test failure paths as well as normal exit. Descriptor leaks are often visible as a gradual count increase rather than a single dramatic error. Measure counts under repeated lifecycle operations, distinguish expected long-lived resources from leaks, and investigate which ownership transition failed instead of raising limits as the first response.