Visual walkthrough — File operations — open, read, write, seek, close

We will follow this exact chain, one picture per link:

Related vault stops on the way: System calls and the kernel boundary, File descriptor table, File system & inodes, Buffered I/O (fopen/fread).

Step 1 — Draw the file as a row of numbered boxes

WHAT. Before any code, picture the raw material. A file is nothing clever: it is a straight line of bytes, and a byte is just one little box that holds a number from 0 to 255. We number the boxes starting at 0. So a 20-byte file is boxes $0,1,2,\dots ,19$.

WHY this picture. Every single call below is defined by which box we are pointing at. If you don't first agree that boxes have addresses $0\dots \text{size}-1$, phrases like "offset 16" or "seek to end" are meaningless. Everything hangs off this ruler.

PICTURE. Look at the row of boxes. The number written under each box is its address (its position). The very first byte is address $0$, not $1$ — this off-by-one is where half of all file bugs live.

Step 2 — open: get a ticket, plant the arrow at 0

WHAT. Your program cannot touch the disk directly (that hardware belongs to the kernel — see System calls and the kernel boundary). So you ask:

$\underset{\text{your ticket number}}{\underbrace{\text{fd}}}=\text{open}(\underset{\text{which file}}{\underbrace{\text{"data.bin"}}},\underset{\text{"I only want to read"}}{\underbrace{\text{O\_RDONLY}}})$

Term by term:

• $\text{"data.bin"}$ — the name; the kernel follows it to the file's inode.
• $\text{O\_RDONLY}$ — the access mode, a promise about what you'll do.
• $\text{fd}$ — the returned file descriptor: the smallest unused small integer (0,1,2 are usually taken by stdin/stdout/stderr, so you often get 3). It indexes your File descriptor table.

WHY a returned number at all? You need a short handle to name "this open file" in every later call. The kernel also creates, off to the side, an open file description box that stores the offset — and it plants that arrow at $0$.

PICTURE. The ticket fd = 3 on the left points into a kernel box holding offset = 0, and that arrow sits just left of byte 0.

Step 3 — read: copy bytes, then slide the arrow right

WHAT. We ask for up to 8 bytes:

$\underset{\text{bytes actually copied}}{\underbrace{\text{n}}}=\text{read}(\underset{\text{ticket}}{\underbrace{\text{fd}}},\underset{\text{your box in RAM}}{\underbrace{\text{buf}}},\underset{\text{how many you’d like}}{\underbrace{\text{8}}})$

The kernel copies bytes starting at the arrow into your buf, then does the crucial thing:

${\text{offset}}_{\text{new}}={\text{offset}}_{\text{old}}+\text{n}$

WHY the arrow moves by n, not by 8. You asked for 8 but got n. The arrow advances by what was actually delivered, so a second read continues exactly where the first left off — automatic sequential reading, no manual counting.

WHY can n < 8? The file might have fewer than 8 bytes left, or (for a pipe/socket) less data has arrived. So n is the truth; 8 was only a wish.

PICTURE. Before: arrow at 0. read copies bytes 0–7 into buf. After: the arrow has jumped to sit left of byte 8. Only the first n boxes of buf are valid — the tail is garbage.

Step 4 — write: same arrow, opposite direction

WHAT. Writing is the mirror of reading — bytes flow from your buf into the file at the arrow:

$\underset{\text{bytes actually stored}}{\underbrace{\text{n}}}=\text{write}(\text{fd},\text{buf},\underset{\text{how many to store}}{\underbrace{\text{count}}})$

and again the arrow slides right by n:

${\text{offset}}_{\text{new}}={\text{offset}}_{\text{old}}+\text{n}$

WHY check n here too? A short write (n < count) can happen if the disk fills or a signal interrupts. So production code loops until everything is out:

ssize_t total = 0, n;
while (total < count) {
    n = write(fd, buf + total, count - total);
    if (n < 0) break;      // real error
    total += n;            // slide our own bookkeeping past what's done
}

PICTURE. The arrow starts at some box; write overwrites boxes rightward and drags the arrow the same distance. Compare the red arrow position to Step 3 — identical motion, bytes just go the other way.

Step 5 — lseek: teleport the arrow without touching a single byte

WHAT. Sometimes you don't want the next byte — you want byte 16, or the last 4 bytes. lseek moves the arrow by pure arithmetic, copying nothing: