POSIX

Software Engineering 17 Sep 2026 8 min read

File-Backed Mappings Can Outlive the File Size They Assume

A process can retain a valid virtual memory mapping after another actor has shortened the mapped file. The address range still exists in the process, but the backing object may no longer contain every page that range once represented. On POSIX systems, an access to a whole mapped page beyond the new end can deliver SIGBUS rather than behaving like an ordinary failed file read. That boundary makes file-backed mmap() different from copying bytes into private heap storage. A pointer into a mapping is not proof that the corresponding file extent still exists. The virtual address, mapping lifetime, file identity, and current file size are related state, but they are not one indivisible object.

Software Engineering POSIX

Tech 16 Sep 2026 5 min read

fsync on a File Does Not Persist Its Directory Entry

A successful fsync() on a regular file does not, by itself, guarantee that the directory entry naming that file has reached persistent storage. Linux documents this boundary explicitly: file synchronization covers the file’s data and associated metadata, while persistence of the containing directory entry requires an fsync() on a file descriptor for that directory. This distinction matters when software creates a new file or atomically replaces an existing pathname. File contents and pathname metadata are separate pieces of filesystem state, and a crash can test the durability boundary between them.

Linux Filesystem

Software Engineering 16 Sep 2026 7 min read

Duplicate File Descriptors Share Offsets but Not Descriptor Flags

Calling dup() does not create an independent stream position. The returned descriptor refers to the same open file description as the source descriptor, so a seek through either descriptor changes the offset observed through both. At the same time, descriptor-local state such as the close-on-exec flag remains attached to each descriptor separately. That split is easy to miss because both kinds of state are manipulated through integer file descriptors. The integer is only a process-local reference. Several descriptors can point at one open file description, and that shared object carries state with consequences for reads, writes, seeks, and status-flag changes.

Software Engineering Linux

Software Engineering 15 Sep 2026 6 min read

Atomic Rename Separates Visibility From Crash Durability

A successful rename() can replace an existing pathname without exposing an interval in which that destination name is absent. That visibility property makes rename a common publication boundary for configuration files, checkpoints, manifests, and other file-backed state. It does not, by itself, establish that the replacement survives an abrupt loss of power. The distinction is between namespace atomicity and persistence. Atomic replacement constrains what concurrent observers can see while the system is running. Crash durability concerns which writes and metadata changes are guaranteed to remain after volatile state disappears. Treating those properties as equivalent creates a gap precisely at the failure boundary that atomic replacement is often intended to protect.

Software Engineering Filesystems