A backend service writes a line to:

The service can stop, restart, and read the line again. Another authorized process can inspect the same data. Neither program needs to know which storage-device blocks contain the line, whether those blocks are adjacent, or how the device represents a write internally.

The operating system makes this possible by presenting a file: a persistent object with data and metadata that applications normally locate through a name. For an ordinary regular file, the data appears to applications as a sequence of bytes.

The file abstraction separates the logical data an application uses from the physical storage that holds it.

This separation is similar to other operating-system abstractions. A process lets software run without managing the CPU directly, and virtual memory lets software use addresses without choosing physical RAM locations. A file lets software retain and retrieve data without managing raw storage locations.

A storage device can hold large amounts of data, but its hardware interface is not a practical application interface. At a low level, storage is addressed in units such as blocks. Those blocks have numeric locations and device-specific rules.

Imagine that every application had to use the device directly:

This arrangement would fail quickly. Applications would need to coordinate storage allocation with one another. A growing log could collide with another application's data. Moving data would invalidate every program that remembered its old physical location. Programs would also need device-specific code and a shared way to protect one another's storage.

A file system takes responsibility for those problems. It organizes stored data and presents file objects through an operating-system interface. Applications use logical names and byte positions; the file system manages the representation underneath.

The layers are deliberately separate. The same application can work when a file is moved to another physical region or when the underlying device is replaced by a different model. The application's view can remain:

The physical representation is an implementation concern behind that view.

The word file is used broadly in operating systems, especially on Unix-like systems. The simplest place to begin is a regular file: the kind commonly used for source code, executable programs, images, configuration, logs, and database data.

Conceptually, a regular file has four important properties:

The system also provides controlled operations for creating, accessing, changing, and removing files. The exact operation mechanics are separate from the abstraction itself. For now, the central contract is that an application can work with a logical object while the file system manages how that object is represented.

This contract is intentionally modest. A regular file does not inherently promise that its bytes form text, that they contain complete records, or that they are meaningful. Those interpretations come from software above the file system.

Suppose a file contains the six ASCII characters hello followed by a newline. Its logical contents can be pictured as:

Each byte has a logical offset. The first byte is at offset 0, the next at offset 1, and so on. A six-byte file has valid byte offsets from 0 through 5; offset 6 is immediately beyond its current end.

These offsets are not storage-device addresses. Offset 4 means “the fifth byte in this file,” not “byte four on the SSD.” The file system translates between the logical view and its internal storage representation.

The byte-sequence model has several useful consequences.

An application can request a range without knowing where it is physically stored. A file can grow or shrink while retaining the same logical identity. Its data can also be relocated underneath the abstraction without requiring the application to update stored device addresses.

Most general-purpose operating systems do not impose application-level record boundaries on a regular file. If a log contains one JSON object per line, the newline convention belongs to the logging format. If a database file contains fixed-size pages, the database engine defines those page boundaries. The file system stores the bytes without understanding the application's schema.

This is why the same file interface can store so many kinds of data:

At the file-system boundary, all three are byte sequences. Their consumers give those bytes meaning.

People often contrast “text files” with “binary files,” but the file system normally stores both as bytes.

A text file uses a character encoding and conventions for representing text. In UTF-8, an English letter commonly occupies one byte, while many other characters occupy multiple bytes. A line ending is also represented by one or more byte values, depending on the convention in use.

A binary format assigns different meanings to byte patterns. Some bytes may encode numbers, offsets, compressed data, pixels, or machine instructions. Values that do not represent printable characters are entirely ordinary in such files.

The file system generally does not validate either interpretation. It does not reject malformed JSON, repair an invalid image header, or ensure that an executable contains valid instructions. Those responsibilities belong to the application, library, or runtime that understands the format.

A filename extension such as .txt, .png, or .db is also a naming convention, not the fundamental type of a regular file. Renaming photo.png to photo.txt changes its name, but it does not translate the PNG bytes into text.

This distinction prevents a common category error:

These are three different facts.

The end of file, commonly abbreviated EOF, is the position immediately after the last byte in the current sequence. It is not a hidden marker stored after the data.

For a file of size 6:

When a program tries to read at or beyond that position, the file interface can report that no more bytes are currently available from the regular file.

No byte value means EOF in every file. The byte 0x00, often called a null byte, is ordinary file data. The byte 0xff is ordinary data as well. An application format may assign a special meaning to some value, but that is separate from the operating system's end-of-file condition.

An empty file makes this especially clear. Its size is zero, so its EOF position is offset 0. The file still exists as an object and still has metadata even though its byte sequence contains nothing.

Applications often refer to files by names such as:

It is tempting to treat that string as the file itself. A better model is:

A pathname tells the operating system how to find a file; it is not the file's data or identity.

This separation explains several everyday observations. Renaming a file does not normally rewrite its contents. Moving a file within the same file system can change how it is found without changing the logical byte sequence. On Unix-like systems, more than one name can refer to the same underlying file object, and an open file can temporarily remain usable even after its last name is removed.

Those behaviors depend on directory and link mechanisms, but their conceptual foundation is simple: names create associations through which file objects can be reached.

The contents do not normally store their own pathname. Copying a file's bytes into a new file does not automatically copy its name, and changing a name does not edit the byte at offset zero.

Keeping name and identity separate gives the operating system flexibility. Applications can organize files into human-readable namespaces while the file system tracks the underlying objects independently.

The byte sequence is only part of a file. The operating system also keeps metadata, meaning data that describes the file as an object.

Common metadata includes:

Metadata is conceptually outside the regular file's contents. If an application reads every byte from offset zero to EOF, it does not receive a header containing the owner, permissions, and filename before the application data.

This matters for both correctness and tooling. A program can replace a file's contents while some metadata remains associated with the file object. Conversely, metadata such as access rules can change without adding or removing bytes from the data sequence.

Different operating systems and file systems expose different metadata fields and timestamp semantics. The abstraction does not require every implementation to record identical information. It does require enough managed state for the operating system to identify the object, interpret its type, control access, and operate on it.

The internal structure used to store file metadata is deliberately hidden from applications. Application code asks the operating system for properties such as size or type rather than reading a fixed device block and decoding a particular file system's private representation.

Memory owned by a process normally disappears when that process terminates. A regular file is designed to have an independent lifetime.

Consider a service that writes its configuration:

This persistence is a defining value of the abstraction. A file can carry information across program executions, system restarts, and communication between different programs.

Persistence does not mean permanence. A file can be removed, overwritten, corrupted by faulty software, or lost with failed storage. Backups and replication address risks that the existence of a file alone cannot solve.

Persistence also should not be confused with an immediate power-loss guarantee. The operating system and storage hardware may temporarily hold recent changes in volatile memory. A successful data-changing operation and durable survival of an abrupt failure are separate milestones. The stronger durability and crash-consistency rules deserve their own treatment; at this point, it is enough to keep the distinction precise.

A file gives data an operating-system-managed lifetime beyond one process, but it does not make that data indestructible.

Operating systems expose several kinds of objects through a file-system namespace. On a Unix-like system, a pathname can identify a regular file, directory, symbolic link, or special object connected to a device or communication mechanism.

A directory is a file-system-managed object used to associate names with other file-system objects. It is not merely a regular text file that applications should edit as arbitrary bytes.

A symbolic link is a distinct object that redirects name lookup. Its precise lookup behavior differs from copying a regular file or creating another name for the same object.

A device file gives applications a file-like interface to a kernel-managed device. /dev/null, for example, accepts bytes written to it and produces no stored byte sequence for a later reader.

Named pipes and some local sockets can also appear in the file-system namespace. They support communication rather than persistent random-access storage.

The important word is type. Objects can share naming and access conventions without sharing all semantics:

This is the useful truth behind the Unix saying “everything is a file.” Unix applies a common style of interface to many I/O objects. The slogan does not mean that every object is a persistent, seekable sequence of bytes.

Why expose different objects through a file-like interface at all?

It lets applications reuse a small set of concepts. A command can send output to a terminal, a regular file, a pipe, or a device without containing hardware-specific code for every destination. Shell redirection works because programs write to a common interface while the shell arranges which object receives that output.

For example:

The program produces the same bytes in all three cases. The destination changes:

Common syntax does not imply identical results. Some file-like objects do not support seeking. Some do not retain data. Some can block while waiting for another process or device. The object type and the requested operation determine the actual behavior.

Applications reach open I/O objects through small handles on Unix-like systems. Those handles and their relationship to open file state are important enough to treat separately. For the file abstraction itself, the key point is that the operating system can present a stable interface while dispatching operations to different underlying implementations.

Consider an order service with three files:

The service gives each byte sequence a different application-level interpretation. It parses the first as JSON, treats newlines in the second as record boundaries, and lets a storage library interpret the third as database pages.

The file system does not need to understand those formats. It provides the underlying objects, logical sizes, metadata, names, and access interface. The service and its libraries provide the schemas.

After a restart, the service can find the configuration and database through their names and reinterpret the stored bytes. The same files can also be inspected by administrative tools that understand their formats.

This division of responsibility is powerful:

The boundary lets a general-purpose file system serve compilers, media tools, databases, and backend services without embedding every application's data model in the kernel.

A short Linux experiment makes the logical view visible. Create a temporary directory and a regular file:

Ask the operating system for the file's type and logical size:

The expected result is:

PENDING occupies seven bytes, its newline occupies one, READY occupies five, and the final newline occupies one:

Inspect the logical bytes and their character interpretations:

The output includes the hexadecimal values:

Nothing in this output records that PENDING and READY are application statuses. The shell command supplied the bytes, and software reading the file must decide how to interpret them.

Now change only the name:

The object is still a regular file with the same 14 logical bytes. The .bin suffix did not convert the data into another format.

Compare that result with a special file:

/dev/null is reported as a character special file. It accepts the write through a familiar interface, but it does not become a 14-byte regular file. The object type determines its semantics.

This experiment exposes the most important parts of the abstraction without revealing any physical storage addresses:

The abstraction deliberately leaves several responsibilities elsewhere.

It does not define a data format. A .json file can contain invalid JSON, and a regular file containing image bytes remains a regular file even if the image is corrupt.

It does not make writes from multiple programs automatically form valid application-level records. The file system manages file operations; applications must still define appropriate coordination and consistency rules for their formats.

It does not promise that logical neighbors occupy physically adjacent storage locations. Applications use byte offsets specifically so physical placement can remain hidden.

It does not guarantee that every file-like object behaves like a regular file. Devices and communication endpoints can accept familiar operations while applying different rules.

It does not make data immortal or guarantee that every recent update has already survived a possible power failure. Persistence, durability, backup, and application correctness are related but distinct concerns.

The abstraction is valuable because it gives applications a stable contract, not because it erases every failure mode below or above that contract.

A regular file is an operating-system-managed object whose data appears as a logical sequence of bytes. Each byte has an offset, and the position immediately after the last byte is EOF. The file system hides physical storage placement so applications can work with logical data instead of device blocks.

The file also has identity and metadata separate from its contents. A pathname helps locate the object but is not the object itself, and a filename extension suggests an application format without determining the operating-system file type.

Files give data a lifetime beyond the process that created it. Other objects, including directories, links, devices, and communication endpoints, can share parts of the file interface without behaving like persistent regular files.

The central mental model is:

An application sees names, metadata, and logical bytes; the file system manages the objects and storage representation behind that view.