1. Start with the Familiar Name

When we interact with persistent storage, we locate and open files using names:

To a user or a programmer, it is natural to assume that the name is the file itself.

But this assumption is incorrect.

A filename is merely a string used to identify an object. It is not the underlying file object, nor is it the physical container of the data. A filename is a name used for lookup within a namespace. The physical data blocks on disk and the metadata describing them have an entirely separate identity.

This separation becomes more apparent when we construct a sequence of names to identify a file—a Path:

A path is not a single physical string stored on disk that points directly to a sector. Instead, a path is a map. It represents a route that the operating system must navigate component by component to find the target object.

2. From Path to File

To resolve the path /home/dev/projects/notes.txt, the filesystem must step through each component of the directory hierarchy:

The process begins at the absolute root of the filesystem namespace. The operating system looks up the root node, retrieves its contents, finds the mapping for home, and traverses downward. It repeats this matching step for dev and projects until it gets the entry for notes.txt.

A path is not a pointer to data. A path is a set of instructions for navigating a hierarchical namespace.

3. Directories Are Not Folders

In graphical user interfaces, directories are styled as "folders"—visual bins that contain physical files.

Conceptually, however, a directory is a mapping table. It is an organizational structure that translates human-readable name strings into unique filesystem internal identities.

A directory provides mappings from names to filesystem objects. When we look up notes.txt inside a directory table, we receive the internal index key. By nesting directory objects inside other directory tables, the filesystem builds the entire hierarchical directory tree.

4. EdgeCase: Path Resolution

Watch the interactive sequence below to trace how the operating system resolves /home/dev/projects/notes.txt from the root node through nested directories, retrieving directory entry tables along the path:

5. The Surprising Part: Name ≠ Identity

Because directories only link names to identities, the name of a file is decoupled from the file itself. This means multiple names can point to the same underlying file identity.

This relationship is known as a Hard Link:

In this system, both report.txt and backup.txt entries are registered inside a directory pointing to the exact same file metadata entry (Inode #7182).

This is not a copy. Both names refer to the exact same file. If a program writes to report.txt and updates its content, a subsequent read of backup.txt immediately reveals those updates. The file remains alive until all names pointing to its inode reference are deleted (reducing the link count to 0).

6. Symbolic Links

Another way to map names is through a Symbolic Link (often called a symlink or shortcut).

Unlike a hard link, which points directly to the file identity, a symbolic link is a separate file that stores a path string referencing another name:

The difference between the two configurations is fundamental: * Hard Link: A direct path from multiple names to the same target inode. * Symbolic Link: A path from a name to a new file object whose data payload contains the text string of another path.

If the target name report.txt is deleted, the symlink latest.txt remains behind but becomes a "broken link," resolving to a path that no longer exists.

7. Relative vs. Absolute Paths

Paths can be specified in two formats:

* Absolute: Starts from the root token (/), e.g., /home/dev/projects/notes.txt. Resolution always begins at root. * Relative: Does not start from root, e.g., projects/notes.txt. Resolution begins from a contextual environment—typically the process's Current Working Directory (CWD).

This context means the same relative path can resolve to different physical files depending on which folder the application is executed from.

8. Real Operating-System Connection

While disk format structures vary across operating systems, the core programming interface remains uniform.

For instance, Linux filesystems (like ext4) implement directory entries as tables mapping name strings to numerical index nodes (inodes). The inode contains all metadata and block addresses, but has no knowledge of the name itself. Regardless of the underlying operating system—be it Windows, macOS, or Linux—the OS presents the exact same unified namespace abstraction (names, paths, directories, and file objects) to user application processes.

9. The Next Question

How does the filesystem keep track of all this information — the file's metadata, its directory entries, its data blocks, and the free space around them?