Files, Directories & Paths

In this chapter

We'll open up what a directory actually is — a real lookup table, not a container — and walk through exactly how a path resolves, one name-to-number lookup at a time, down to the file the customer's missing invoice actually points at.

7–9 min

The Problem in Real Life

Sarah pulls up the server's file listing for the missing invoice. "The customer's receipt should be at /data/invoices/2026/inv-4471.pdf," she says. "That's not a real 'place' the way a street address is a place. It's a path — a set of directions."

Mike squints at the slashes. "Directions to what, exactly?"

Isn't a folder just... a folder? Why does the path matter that much?

Mike

A Folder You See vs. A Table the File System Reads

A directory is a table, not a container

Every directory entry maps a name to an inode number — it doesn't hold the file's bytes, just a name and a real pointer.

A path is a real, mechanical walk

Resolving a path means one real lookup per segment, chaining through directory tables until the final name resolves.

A directory (what most people call a folder) isn't a container the way a real physical box is a container. It's a real, ordinary lookup table: a list of names, each one paired with a number pointing at where that name's actual file lives. A path is just a set of directions for walking through a chain of these tables, one directory at a time.

A directory is a table of name → number. Every entry in a directory maps a real file name to a real inode number (a chapter ahead covers what an inode actually holds) — not to the file's content directly. This is a small but genuinely important distinction: a directory doesn't store a file's bytes, or even a pointer to them; it stores a name and a number, and that number is the real key used to find everything else.
A path is a real walk, one step at a time. Resolving /data/invoices/2026/inv-4471.pdf means: look up data in the root directory's table, get a number, go to the directory that number identifies, look up invoices in that directory's own table, get another number, and so on — one real, mechanical lookup per path segment, until the final name resolves to the actual file. Nothing about this walk is instant or magical; it's a genuine sequence of real lookups, and a slow disk (Act 1's own vocabulary) makes a deep path a real, measurable cost.
Absolute vs. relative — where the walk starts. A path starting with / (an absolute path) always starts the walk from the real root directory, no matter where a running program currently is. A path without that leading / (a relative path) starts from wherever the program's current working directory happens to be — the exact same relative path, run from two different starting points, can resolve to two completely different real files.
One name, one inode number — but not necessarily the other way around. A single directory entry always points at exactly one inode number. What a later chapter in this Act (Hard Links) reveals is that the reverse isn't true: more than one directory entry, even in different directories, can genuinely point at the very same inode number — the very fact that makes GreenMart's missing-invoice mystery possible.

Resolving /data/invoices/2026/inv-4471.pdf — one lookup per segment

Root directory (/)

table: name → inode #

look up "invoices"

data/ directory

table: name → inode #

look up "2026"

invoices/ directory

table: name → inode #

look up "inv-4471.pdf"

2026/ directory

table: name → inode #

inv-4471.pdf

resolves to a real inode number

This is the real mechanism underneath the folder icon Mike takes for granted every day: not a physical container, but a chain of ordinary lookup tables, walked one real step at a time, each step trading a name for a number.

Key Takeaway

A directory doesn't hold files — it holds a table mapping names to inode numbers, and a path is nothing more than real directions for walking that chain of tables, one lookup per slash.

Why This Matters

Every file operation GreenMart runs — an upload, a download, a backup job scanning a directory tree — pays the real cost of this walk. Understanding it explains real, everyday behavior: why a deeply nested path can be measurably slower to open, and why the same relative path can point at two different files depending on where a script actually runs.

GreenMart now understands a name as a real entry in a real table, resolving to an inode number through a real, mechanical walk. The next chapter opens that number up: what an inode actually stores about a file, separate from its name entirely.