1. Start from the Problem

When an application creates a new file, the operating system must perform a lot of bookkeeping. Suppose your program requests:

To manage this file, the operating system cannot simply store a list of active filenames. It must be prepared to answer critical operational questions at any time:

* What does this file represent? Is it a regular file, a directory, a symbolic link, or a character device? * How large is it? Where does the file end, and how many bytes are in use? * Who owns it and who can access it? What are the read, write, and execute permissions? * When was it changed? When was the file created, modified, or last opened? * Where is its data? Which physical block sectors on the storage media hold the file's content? * Which blocks are free? Where can the filesystem allocate space when the file expands? * How does it survive a power loss? What happens to the metadata if the machine suddenly shuts down mid-write?

To resolve these questions, the operating system relies on persistent filesystem structures written directly onto the storage device.

2. The Conceptual Filesystem Structures

To organize this information, modern filesystems split their responsibilities among four major conceptual layers:

Directory Entries The namespace is the human-facing interface of the filesystem. The directory structure answers: What name refers to which filesystem object?

Directory records are lookups mapping filenames to internal system identifiers:

File Metadata Once the filename maps to an internal ID, the operating system accesses the metadata record. It answers: What is this file?

The metadata block contains everything about the file except its name or its raw data: * File size (in bytes or sectors). * Owner and group membership. * Access permissions (Read/Write/Execute constraints). * Timestamps (creation, modification, access). * File type (regular, folder, link, etc.). * Link count (number of directory entry references). * Data location offsets (pointing to where the data blocks are located).

Data Allocation Information To read or write the actual data payload, the OS consults the location map stored in the file's metadata. It answers: Where are the contents of this file stored?

Conceptually:

The exact indexing mechanisms vary, ranging from sequential block indexes to extent maps (which reference a starting block and a run length).

Free-Space Tracking When files grow or new files are created, the filesystem needs to know: Which storage blocks are available for new data?

Conceptually, the filesystem maintains a map of the drive:

The OS reads this structure to find free space quickly and update its markers as sectors are assigned.

3. The Key Realization

A filesystem is not just a bucket where you store files.

Without these background structures, the storage drive is merely a flat, raw string of addressable sectors. The filesystem is the translation machinery that converts raw sectors into a structured digital workspace.

4. EdgeCase: The Lifecycle of a File

Use the simulator below to trace how the operating system coordinates directories, metadata tables, space trackers, and storage sectors during the lifecycle of a file:

5. Important Conceptual Distinction

When you click "Delete" in the simulator above, notice that the physical data blocks are not wiped.

When a file is deleted, the operating system typically does not overwrite the physical sectors with zeros immediately. Instead, it: 1. Removes the name mapping from the directory. 2. Releases the metadata record (making its ID available for new files). 3. Marks the data blocks as "free" in the space tracker.

The old data remains physically readable on the drive sectors until it is overwritten by a subsequent write operation.

6. Real Operating-System Connection

While the concepts remain uniform, different operating systems organize their directories and metadata structures in unique ways:

Unix / Linux (ext4, XFS) Linux filesystems separate names from properties using index nodes (inodes). Directory entry records map name strings directly to inode numbers. Each inode stands as a self-contained record pointing to the file metadata and data block pointers.

Windows (NTFS) NTFS stores all file data and properties in a database called the Master File Table (MFT). MFT records contain the attributes of a file, such as its name, security permissions, and either the data itself (for very small files) or references to external data clusters.

macOS (APFS) APFS uses a b-tree object map, dynamically scaling metadata nodes to manage file snapshots, space sharing, and quick lookups without hardcoded layout layouts.

Regardless of the on-disk implementation details, every operating system must provide matching mechanisms for directory names, metadata properties, data tracking, and free-space bookkeeping.

7. The Next Question

We now understand how the filesystem keeps track of files.

But what actually happens underneath the filesystem when it asks the storage device to read or write those blocks?