This article explains how a specific file path leads to a file’s metadata and stored contents.
From the user’s point of view, a file looks like one simple object.
In a folder, a user sees a name such as report.pdf. The file can be opened, moved, renamed, or deleted as if it were one single object.
But that view hides an important question: where is the name report.pdf actually stored, and how is it connected to the file’s contents?
This document focuses on the layer between raw storage and the user-facing file view. It explains how a file system connects names, folders, metadata, and contents into the files users see.
This document uses a Unix-like file system model, where directory entries map names to inode numbers.
The Layers at a Glance
A file, as users experience it, is not produced by one layer alone. It is the result of several layers working together.
- User view: sees files and folders. It shows objects such as
report.pdfthat users can open, rename, and move. - File system: sees names, folders, metadata, and content locations. It connects file names to metadata and connects metadata to stored contents.
- OS storage stack: sees block I/O requests. It turns file-system requests into lower-level read and write requests.
- Storage device: sees LBA ranges. It reads or writes ranges identified by a starting LBA and a transfer length.
- Physical media: stores bits in flash cells, magnetic domains, or another physical medium. The device firmware decides how host-visible logical addresses map to those physical locations.
This document focuses mainly on the middle of this chain. It explains how a file system connects the user-facing file view to lower-level stored data.
Resolving a File Path
Suppose a program asks the operating system to read the file at /home/user/report.pdf.
When the operating system receives a path, it resolves the path step by step through directories until the final name maps to the inode for the target file.
A directory also has an inode. From the user’s point of view, it looks like a folder that contains files. Inside the file system, its main role is different. Its directory data stores entries that map names to inode numbers.
In a Unix-like file system, this can be understood as a collection of directory entries. Each entry connects a name to an inode number, and that number identifies an inode. The exact structure depends on the file system, but the idea is the same. A directory helps the file system find the next file or directory by name.
For /home/user/report.pdf, each step looks inside one directory and follows one directory entry:
| Directory | Entry name | Entry maps to |
|---|---|---|
/ | home | inode number for directory /home |
/home | user | inode number for directory /home/user |
/home/user | report.pdf | inode number for file /home/user/report.pdf |
The final directory entry, report.pdf, does not contain the PDF bytes. It contains the inode number that identifies the file’s inode. The next step is to understand what that inode represents.
A Directory Stores Name-to-Inode Entries
Within one mounted file system, an inode number identifies an inode, and the file system uses that number to find the inode. The inode stores metadata for a file or directory, including its type, permissions, size, and content-location information. A file or directory name is stored separately in a directory entry, which maps that name to the inode number.
For example, suppose the user opens the folder /home/user and sees these items:
report.pdfmemo.txtphotos
From the user’s point of view, /home/user looks like a folder that contains those objects.
Inside the file system, however, /home/user is a directory object. Its directory data stores entries that connect visible names to inode numbers. Conceptually, it may contain entries like this:
| Entry name | Inode number |
|---|---|
report.pdf | 12345 |
memo.txt | 12346 |
photos | 12347 |
The directory entry for report.pdf does not contain the PDF bytes. It only says that the name report.pdf is associated with inode number 12345.
The file system then uses inode number 12345 to find the inode for report.pdf. That inode describes the file and points to the storage locations where the file’s contents are stored.
If the entry points to a directory, such as photos, the file system can load that directory’s inode and then read that directory’s own entries. That is how path resolution continues from one directory to the next.
Metadata Points to File Contents
The final directory, /home/user, has a directory entry like this:
| Name | Inode number |
|---|---|
report.pdf | 12345 |
The entry does not store the PDF bytes. It stores the name report.pdf and the inode number that identifies the file’s inode.
The inode number 12345 identifies the inode for report.pdf. The file system uses that number to find the inode.
The inode does not store the file name. The name report.pdf is stored in the directory entry. The inode stores metadata about the file and information about where the file’s contents are stored.
Conceptually, the inode for report.pdf may contain information like this:
| Inode component | Example for report.pdf |
|---|---|
| File type | regular file |
| Permissions | rw-r--r-- |
| Owner | user id, group id |
| Size | 204,800 bytes |
| Timestamps | access time, modification time, change time |
| Link count | 1 |
| Content-location information | block pointers or extents |
| Block count | number of allocated blocks |
| Optional metadata | ACLs or extended attributes |
The exact fields depend on the file system, but the main idea is the same. The inode stores the file’s metadata and the information needed to find its contents.
The inode’s content-location information maps file offsets to file-system blocks or extents on the backing block device.
Conceptually, the file system maps parts of the file’s contents to logical block ranges on the block device it is mounted on. Those ranges are still file-system-level or block-device-level locations, not necessarily the final physical locations on the storage media.
After any necessary block-device mappings, such as partition, LVM, RAID, or device-mapper mappings, those logical block ranges are translated into the starting LBA and transfer length used in the final storage-device read/write command.
When the operating system sends a read or write request to a storage device, it identifies the target range using a starting LBA and a transfer length.
An LBA, or Logical Block Address, is a logical block number that a storage device exposes to the operating system. The transfer length tells the device how much data to read or write from that starting point.
What Rename, Move, and Delete Change
The separation between directory entries and inodes explains several everyday file operations.
Renaming a file usually changes a directory entry, not the file’s contents. If report.pdf becomes final-report.pdf in the same directory, the name changes, but the inode and data blocks can remain the same.
Moving a file within the same file system can also be cheap. The file system can remove a directory entry from one directory and add a directory entry in another directory that points to the same inode.
Deleting a file removes a directory entry and decreases the inode’s link count, which tracks how many directory entries still point to the inode. The file’s storage can be freed only when no directory entries and no open file handles still refer to the inode.
Conclusion
A file is not stored as a single visible object on the device. The user-facing file is built by the file system from several connected pieces.
A directory entry connects a visible name to an inode number. The inode stores metadata and content-location information. The file system uses that information to find the file’s data on its backing block device. Lower storage layers then translate those logical locations into the LBA ranges used by the storage device.
The important idea is that the file name, the metadata, and the file contents are related, but they are not the same thing. A file system makes them appear as one file by connecting them through its own structures.