1. The Familiar Assumption

When writing code to interact with persistent storage, we often start with a simple command:

To a programmer starting out, it is easy to assume a direct, unmediated relationship: the application requests a file, grabs it, and reads or writes its bytes directly from the disk.

But this mental model is an illusion.

An application cannot directly access physical storage devices. The CPU runs program code in a restricted, unprivileged mode (User Mode). In this execution space, program instructions cannot issue raw commands to storage interfaces. If an application could touch storage sectors directly, a single bug or malicious loop in one program could overwrite the partition table, corrupting the entire system.

To interact with a file, the application must cross a strict architectural boundary.

2. Crossing the Boundary

To access a file, the program must request the operating system kernel to perform the operation on its behalf. It does this by using a set of dedicated functions called System Calls.

These calls represent the secure interface through which applications query the kernel:

* open(): Requests access to a file by name. * read(): Requests bytes from a previously opened file resource. * write(): Requests bytes into a previously opened file resource. * close(): Releases the resource.

It is important to make a conceptual distinction: these system calls are not File Management itself. They are simply the API—the doors in the wall. File Management is the massive, complex infrastructure running inside the kernel that handles access verification, data buffering, filesystem block mapping, and storage scheduling behind those doors.

3. The File Descriptor: A Digital Ticket

When an application invokes open("notes.txt"), the kernel does not send the physical file data to the application. Instead, if the request is valid, the kernel returns a simple integer:

This integer is a File Descriptor (often abbreviated as fd).

The application does not receive a pointer to raw storage or the filesystem structures. It receives a reference index. When the application needs to read data, it passes this index back to the kernel:

Conceptually, we must separate three distinct ideas:

* The File: The persistent resource resting on storage (defined by its metadata/inode and data blocks). * The Open File (Description): The temporary tracking state allocated by the kernel when a file is opened (storing the current read/write cursor offset, access flags, and links to the file metadata). * The File Descriptor: The process-specific integer index that references the kernel's open-file table.

The application holds only the descriptor index. The operating system retains complete control over the file state.

4. EdgeCase: The Open File Lifecycle

Watch the interactive sequence below to see how execution transitions across the system-call boundary, how descriptors are mapped in the process table, and how the kernel tracks file offsets:

5. Multiple Processes and Shared Files

Because descriptors are private indexes mapped inside a process's file descriptor table, different processes have separate descriptor namespaces.

If Process A and Process B both open "notes.txt" independently, they do not automatically share the same open file state:

Each process receives its own descriptor (which might happen to be the same integer, e.g. 3) mapping to a separate Open File entry in the kernel's global table. Each entry maintains its own read/write cursor offset. If Process A reads 10 bytes, its offset advances to 10, while Process B's offset remains at 0.

However, in certain scenarios (such as when a process forks or passes descriptor references through IPC), different processes can share the exact same kernel-managed open file state. In that case, an offset advance by one process directly affects where the other process will read or write next.

File descriptors belong to individual processes, but open-file states and files are distinct kernel-wide resources.

6. Diverse Handles, Uniform Concept

The exact names and mechanisms for this reference system differ across operating systems, but the underlying architectural pattern is identical:

* Unix / Linux / POSIX: Relies on integer-based File Descriptors. Standard streams are pre-allocated: 0 (stdin), 1 (stdout), and 2 (stderr). * Windows: Applications invoke APIs like CreateFile() and receive a HANDLE (a pointer-sized opaque reference) rather than a small integer.

In both paradigms, the application receives a reference token. The process never interacts with the storage driver directly; it requests operations using the token, and the operating system handles the translation.

7. The Name-to-Identity Mapping

We now understand that an application does not directly hold the physical file. It uses a file descriptor or reference index to ask the operating system to perform operations on the file. The kernel maintains the open file state and delegates block lookup to the filesystem.

But this relies on the file already being identified by name.

When the application requests:

/usr/local/bin/prog

How does the filesystem find the file that this name refers to?