File

A file is a named, persistent sequence of bytes managed by an operating system, the basic unit in which a computer stores information that must outlast the program or power cycle that produced it. A photograph, a spreadsheet, a program's executable code and a log of web requests are all files, and to the operating system they look identical at the lowest level: an ordered run of bytes with a length and some descriptive information, whose meaning is supplied entirely by whichever program reads it.

The file is an abstraction that hides the physical layout of storage. A disk or flash chip is a grid of fixed-size blocks with no notion of names or documents; the file system presents a file as a continuous stream even if its content is scattered across many blocks, grows and shrinks it on demand, and lets programs read or write at any byte offset. The idea was refined in Multics in the 1960s and then radically simplified in Unix, begun by Ken Thompson and Dennis Ritchie at Bell Labs around 1969, where a file is just an unstructured byte stream and no record formats are imposed by the system. That decision is why the same small set of operations works on nearly everything.

A file's identity is its content plus its metadata, not its name. Metadata normally includes the size, timestamps for creation, modification and access, the owner, and permission bits that govern who may read, write or execute it. On Unix-style file systems this information lives in a structure called an inode, and the human-readable name is merely an entry in a directory that points to it, which is why one file can have several names (hard links) and why renaming never rewrites the content. NTFS keeps comparable information in its master file table, and also supports extra named data streams attached to a file. Because the name is stored outside the file, renaming a file to end in .jpg does not make it a JPEG.

Program calls open on a name
for example, results.csv for reading
Kernel finds the file and checks permissions
name resolved to an inode or equivalent record
Returns a small integer handle
a file descriptor in Unix, a handle in Windows
Operations through the handle
read
copy the next bytes into program memory
write
append or overwrite bytes at the current offset
seek
move to another byte offset
close releases the handle
buffered writes are flushed to storage

Programs work with files through handles, not names. After a program opens a file, the kernel returns a small integer called a file descriptor (a handle on Windows) that stands for the open file together with its current position, and every later read, write or seek goes through it. This design is the origin of the Unix principle that "everything is a file": terminals, pipes, sockets and devices are all given file descriptors, so a program written to read from a file can often read from a keyboard or a network connection unchanged. Open files also carry practical limits, since every process may hold only a limited number of descriptors, which is why programs that forget to close files eventually fail with a "too many open files" error.

The distinction between text and binary files is one of interpretation rather than storage. A text file is bytes that follow a character encoding such as ASCII or UTF-8 so a human or a text editor can read them, while a binary file uses bytes for anything else, such as compressed images, executables or databases. Pitfalls follow from this: line endings differ between Unix (a line feed) and traditional Windows (carriage return plus line feed), and opening a binary file as text can corrupt it. Because most formats are just bytes with a defined layout, formats such as CSV, JSON, Parquet, HDF5 and the checkpoint files of machine-learning models are all simply files, and data science workflows largely consist of reading, transforming and writing them.

Files are not as durable or atomic as they seem, and several misconceptions cause real data loss. Deleting a file removes its directory entry and frees its blocks for reuse, and the bytes may linger on disk until overwritten, which is why undelete tools sometimes work and why secure erasure needs more than deletion. A write that returns successfully has often only reached the operating system's memory cache; a program must request a flush (fsync) before power loss is safe, and robust software writes a new temporary file and renames it over the old one to avoid leaving a half-written result. Finally, a file is not the same as the folder it appears in, the file system that organizes it, or the path used to find it, each of which is a separate idea.

Read a file as a named, durable stream of bytes with attached metadata: the operating system promises only that the bytes come back in order, and everything that makes them a picture, a program or a trained model is agreement between the program that wrote them and the program that reads them.

Take file further

Ask the copilot about this term, or have our engineers assess it against your process.