The most familiar thing you have never defined
You climbed the storage rung and learned the uncomfortable truth underneath everything: a disk is a long, flat array of numbered blocks, each block a brutally slow few-thousand-byte chunk of spinning metal or flash. That is honest, but nobody wants to live there. Nobody opens a document by asking for 'logical block 42,891.' Instead we say 'open my essay,' and it just works. The gap between those two worlds — raw numbered blocks below, a thing-you-can-name above — is exactly the gap the file abstraction closes, and this whole rung is the story of how the OS builds and defends that bridge.
So let us refuse the icon and ask the blunt question: what is a file, really? The plainest honest answer is that a file is a named collection of related bytes stored on persistent storage. Strip away everything else and that is the core: it has a name so a human can find it, it is bytes so it can hold anything, and it is persistent so it survives the power going off — unlike the volatile RAM where a running program lives. The OS is making a promise: give me bytes under a name today, and tomorrow, after a reboot, the same name hands the same bytes back.
Contents are not the whole file: attributes
If a file were only its bytes, you could never sort by date, see a size in the file browser, or be told 'permission denied.' All of that comes from a second, separate part of every file: its attributes — the bookkeeping the OS keeps about the file, stored apart from the contents. Think of it like a library book: the bytes are the story printed on the pages, but the attributes are the catalog card — title, shelf location, who may borrow it, when it was last checked out. The card is not the story, yet the library would be unusable without it.
Typical attributes include the name, a size in bytes, timestamps (created, last modified, last accessed), the owner and group, and the protection bits that decide who may read or write it. There is one more attribute worth singling out: the file's type. How does the OS know your file is a picture and not a program? Two common tricks. On Windows, the type is guessed from the extension — the part after the dot, like .jpg or .exe — which is just a naming convention anyone can change. Unix-style systems often peek instead at the first few bytes: many file formats begin with a fixed signature called a magic number (a PNG image, for instance, always starts with the same handful of bytes), which is harder to fake by renaming.
A file is a verb, too: the operations
A file is not just a noun the system stores; it is also the small set of things you can do to it. These file operations are deliberately few, because the dumb-byte-stream view lets the same handful work on everything. The essential six are: create (bring a new empty file into existence), open (tell the OS you are about to use this file, so it can set up its bookkeeping), read (copy bytes out of the file into your memory), write (copy bytes from your memory into the file), delete (remove it), and close (tell the OS you are done). Almost everything you ever do to a file is some combination of these.
Two of these deserve extra attention because beginners skip them. open is not a formality — it is where the OS does real, expensive setup work once so that later reads and writes can be cheap, and it is the subject of the very next guide. And close matters more than it looks: the OS may hold your written bytes in a fast memory buffer (you met this idea as the buffer cache in the storage rung) and only push them to slow disk later, so closing — or explicitly flushing — is part of how you make sure your bytes actually landed. Forgetting to close is a classic way to leak resources and, occasionally, to lose data that was still sitting in a buffer.
How you point at bytes: handles, position, access
When you open a file, the OS does not keep handing you the long path name every time you read — that would be wasteful, since it would have to re-find the file on disk for each operation. Instead, open returns a small integer called a file descriptor: a numbered ticket that stands in for the open file for the rest of the session. From then on you say read(fd, buf, n) — 'using ticket fd, copy n bytes into buffer buf' — and the kernel uses the ticket to look up everything it already prepared. The next guide opens up the table behind that ticket; for now, just hold the picture of a cheap number standing in for an expensive lookup.
There is a second thing the OS tracks behind that ticket: a file position, often called the cursor or offset. A file is a sequence of bytes, and the position is simply 'where in that sequence the next read or write will happen.' Every read of n bytes nudges the position forward by n, so reading again naturally continues where you left off — exactly like a bookmark advancing through a book. This is why two programs that open the same file each get their own private position: the bytes are shared, but each open has its own bookmark. Walking through a file front to back, letting the position march forward, is called sequential access.
Sequential is not the only way. With a seek operation you can jump the position directly to any byte offset — say, straight to byte 5,000 — and then read; this is direct (random) access, and it is what makes a database able to leap to record number 3,000 without crawling past the first 2,999. Which access method a program uses is a real choice with real costs: on the spinning disk from the last rung, jumping around means paying seek and rotation again and again, which is why sequential reads fly and random reads crawl. The file abstraction lets you do either; the physics underneath decides what it costs.
From one file to many: directories and names
One file is easy. Ten thousand files is chaos — unless you have a way to organize and find them by name. That is what a directory (a folder) is: at heart, just a special file whose contents are a list mapping human-readable names to the files inside it. Crucially, the directory entry holds the name, but the file's real attributes and the location of its bytes usually live elsewhere, in a per-file record. On Unix-style systems that record is the famous inode — every file has one inode holding its size, owner, permissions, timestamps, and the block addresses of its data — while the directory simply pairs a name with an inode number. The name and the file are two separate things, joined by the directory; that one idea is the seed of hard links, which guide four in this rung will grow into something powerful.
Directories can themselves contain directories, and that nesting gives the tree-structured directory you know from any file browser: one root at the top, branching down into folders within folders. To name a file in this tree you give a path name — the trail of directory names from a starting point down to the file, like /home/ana/essays/draft.txt. An absolute path starts from the single root and is unambiguous everywhere; a relative path starts from your current working directory (the folder you are 'in' right now) and is shorter for nearby files. Guide three in this rung walks the whole tree — including how to share one file under two paths, and how 'mounting' grafts a second disk into the same tree as if it were always there.
DIRECTORY (a list of name -> inode#) INODE #1733 DATA BLOCKS +----------------+---------+ +-------------+ +----------+ | name | inode # | | size, owner |--->| the | +----------------+---------+ | perms, time | | actual | | draft.txt | 1733 | -------------> | block ptrs | | bytes | | notes.md | 1810 | +-------------+ +----------+ | photos/ (dir) | 1902 | +----------------+---------+ the NAME lives in the directory; the FILE (attributes + bytes) lives in the inode
Whose file is it? A first look at protection
On any machine shared by several users — or just several programs — a file needs an answer to 'who is allowed to touch this, and how?' That is protection, and the classic, wonderfully compact scheme lives right in a file's attributes as nine permission bits. The OS divides the world into three groups — the file's owner, its group, and everyone else (other) — and for each group it stores three bits: may you read it, write it, or execute it (run it as a program). Written out, those nine bits look like rwxr-xr-x, and the same thing as the number chmod 755: the owner may read, write, and execute; group and other may read and execute but not write.
Nine bits are gloriously simple, but be honest about the limit: three groups is coarse. What if you want exactly Ana and Bao to write, but no one else, and they are not the same group? The bits cannot express that. The richer answer is an access-control list, an ACL, which attaches a full per-user (and per-group) list of allowances to the file — more flexible, but heavier to store and reason about. Both schemes, and the deeper ideas behind them, are the subject of guide five. For now, simply notice that the contents, the attributes, and the protection are three distinct layers of one file, and you have already met all three.