Filesystems

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

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

Python 08 Sep 2026 8 min read

Copy and Move Paths with pathlib in Python 3.14

Python 3.14 adds high-level copy and move operations directly to pathlib.Path. Path.copy(), Path.copy_into(), Path.move(), and Path.move_into() make many filesystem workflows easier to express without switching between pathlib, shutil, and os for basic operations. The convenience is useful, but filesystem mutations still need explicit policy. Overwrites, symbolic links, metadata, cross-filesystem moves, partial failure, and concurrent changes can all affect correctness. The four new operations Use copy() when the destination path itself is known:

Python pathlib

Linux 04 Sep 2026 8 min read

Write Files Atomically on Linux with rename and fsync

Updating a small file looks simple: open it, truncate it, write the new contents, and close it. That works when nothing interrupts the write. The failure mode appears when a process crashes, the machine loses power, or another process reads the file while it is being rewritten. A reader can observe an empty or partially written file, and a crash can leave the pathname referring to incomplete data. For configuration files, state snapshots, generated metadata, and similar single-file updates, a better pattern is to write a complete replacement beside the original file and then rename it into place.

Linux Filesystems