Filesystem

Linux / 19 Sep 2026 / 6 min read

openat2 Constrains Path Resolution at the Kernel Boundary

A pathname that begins inside a trusted directory can resolve somewhere else before open() returns. Parent components, symbolic links, magic links, mount points, and concurrent namespace changes all participate in Linux pathname lookup. Checking a string before opening it therefore does not establish where the kernel will finish resolution. Linux openat2() places restrictions inside the lookup operation itself. A caller supplies a directory file descriptor, ordinary open flags, and a resolve policy in struct open_how. The kernel then applies those constraints while walking every relevant path component. This moves a security boundary from pre-validation of pathname text into the operation that actually resolves the pathname.

Linux Filesystem

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

Python / 09 Sep 2026 / 13 min read

Reduce Filesystem Stat Calls with Python Path.info

Filesystem code often looks cheap until it runs over a directory with hundreds of thousands of entries. A loop that asks whether every path is a file, directory, or symbolic link can translate into a large number of metadata queries. On a local SSD that cost may be tolerable. On network filesystems, container-mounted volumes, or very large trees, repeated metadata lookups can become a noticeable part of runtime. Python 3.14 adds Path.info, a cached file-type information interface on pathlib.Path. It is especially useful when paths come from Path.iterdir(), because Python may initialize the cache with information already obtained while scanning the directory.

Python Python 3.14

Python / 08 Sep 2026 / 8 min read

Walk Directory Trees Safely with Python pathlib Path.walk

Python 3.12 added pathlib.Path.walk(), bringing directory-tree traversal directly to Path objects. It fills the same broad role as os.walk(), but keeping traversal and path manipulation in pathlib can make filesystem code easier to read. Walking a tree is deceptively simple, though. Production code needs to decide which subtrees to enter, what to do with unreadable directories, whether symbolic links should be followed, and whether the filesystem may change during traversal.

Python pathlib

Go / 08 Sep 2026 / 7 min read

Contain Untrusted File Access in Go with os.Root

Applications often combine a trusted directory with a file name that came from somewhere less trusted: an HTTP request, archive entry, manifest, job message, or database row. The obvious implementation is also a common security boundary mistake: path := filepath.Join("./uploads", userName) f, err := os.Open(path) If userName can select a path outside ./uploads, the application may expose files it never intended to touch. Even careful string validation becomes harder when symbolic links and concurrent filesystem changes enter the picture.

Golang Security

Python / 08 Sep 2026 / 5 min read

Change Working Directories Safely with contextlib.chdir

Changing the current working directory is one of those operations that looks local in code but is global in effect. I still see scripts that call os.chdir(), do some work, and then try to remember where they started. Python 3.11 added contextlib.chdir(), which makes the restore step much cleaner. To be fair, though, a context manager does not make changing the working directory concurrency-safe. The important part is understanding what state is being changed and how long that state stays changed.

Python contextlib

Linux / 01 Sep 2026 / 4 min read

Find Hidden Linux Disk Usage with df, du, and lsof

A Linux filesystem can report 95% usage in df while du appears to account for much less. The tools are not contradicting each other: they measure different things. df asks the filesystem about allocated blocks. du walks visible directory entries and sums blocks reachable through those paths. The gap between those views points to several useful troubleshooting cases. Start with the filesystem view Check filesystems and their types: df -hT Identify the mount that is actually full. Do not immediately scan recursively from /; container mounts, network filesystems, and bind mounts can make that slow and misleading.

Linux Troubleshooting