File operations — open, read, write, seek, close: Worked examples

This page is the exhaustive worked-examples companion to 4.2.32 File operations — open, read, write, seek, close. We stop saying how open, read, write, lseek, close behave and instead drive them through every case — every sign of an offset, every degenerate input, every limiting value — until no scenario can surprise you.

The scenario matrix

Every situation these five calls can throw is one of the cells below. The examples that follow are each labelled with the cell they cover, and together they hit all of them.

Cell	Case class	What makes it tricky
A	`lseek` positive offset, `SEEK_SET`	absolute jump forward
B	`lseek` negative offset, `SEEK_END`	"N bytes before end" — sign matters
C	`lseek` offset past EOF + write	creates a sparse file (a hole)
D	`lseek` at exact boundary (offset = 0, offset = size)	degenerate/edge position
E	`read` returns `n < count` (short read)	small file / partial data
F	`read` returns `0`	EOF — not an error
G	`read`/`write` returns `-1`	genuine error, `errno` set
H	`write` short write → loop	must resume from `buf + total`
I	`open` degenerate: missing file, no `O_CREAT`	fails, returns `-1` (ENOENT)
J	Limiting value: fd exhaustion (`ulimit`)	leaking fds until `open` fails
K	Real-world word problem	concurrent append logging
L	Exam twist	offset arithmetic under `O_APPEND` + `SEEK_CUR`

Building the picture: the offset number line

Before the examples, one image. The offset is a single non-negative integer — a bookmark position measured in bytes from the start of the file. Everything lseek does is arithmetic on this one number.

Figure — File operations — open, read, write, seek, close

Worked examples

Example 1 — absolute forward jump (cell A, D)

Example 2 — negative offset from end (cell B)

Apply the SEEK_END formula. newpos = size + offset = 20 + (-4) = 16. Why this step? SEEK_END starts at position = size (20). A negative offset walks backwards from there — this is the idiom for "the last N bytes."

Read 4 bytes at offsets 16, 17, 18, 19 → the final four bytes. Offset ends at 16 + 4 = 20 = size (bookmark now at EOF). Why this step? size - 4 is the first of the last four indices; reading to size exactly consumes the tail.

The -25 degenerate case: newpos = 20 + (-25) = -5 < 0. A negative result is illegal — lseek returns -1 and sets errno = EINVAL. Nothing moves. Why this step? Cell B must also cover the invalid sub-case: you cannot seek before the start of the file.

Verify: last valid index is size-1 = 19; our four indices end at 19. ✔ For -25: 20-25 = -5, and a bookmark can't be negative, so failure is correct. ✔

Example 3 — seeking past EOF creates a hole (cell C)

Seek to 100 on a size-0 file. newpos = 100. This is allowed — seeking past EOF is legal; it does not yet grow the file. Why this step? lseek only touches the offset integer (mistake-killer: it moves no data), so it happily lands past the current end.

Write 1 byte at offset 100. Now the file must be at least 100 + 1 = 101 bytes. Bytes 0–99 were never written. Why this step? The gap between old size (0) and the write position (100) becomes a hole.

The hole reads back as zeros. Any read over bytes 0–99 returns \texttt{0x00}. On disk the hole may occupy no real blocks — that's a sparse file. Why this step? The filesystem records "these blocks are implicitly zero" rather than storing 100 literal zero bytes.

Verify: logical size = \max(\text{old size}, \text{write end}) = \max(0, 101) = 101. Byte 100 holds 'X'; bytes 0–99 read as 0. ✔

Example 4 — short read on a tiny file (cell E, F)

Worked example Statement

A file holds exactly 7 bytes. You loop read(fd, buf, 100) twice. What does each call return?

Forecast: first return? second return?

First read. Offset 0, ask for 100. Only 7 bytes exist → read returns n = 7 (a short read, cell E). Offset advances to 7. Why this step? read returns up to count; when fewer bytes remain, n < count. This is normal, not an error.
Second read. Offset is now 7 = size. There is nothing left → read returns 0 (cell F, EOF). Offset stays at 7. Why this step? A return of 0 is the only signal for end-of-file. Errors would be -1.
Correct copy idiom. write(1, buf, n) uses n = 7, never 100 — bytes 7–99 of buf are uninitialised garbage. Why this step? Only the first n bytes of the buffer are valid.

Verify: total bytes delivered = 7 + 0 = 7 = file size. ✔ Loop terminates correctly the instant it sees 0. ✔

Example 5 — the short-write loop (cell H)

Worked example Statement

You must write a count = 300-byte buffer, but the first write only manages 120 bytes. How does the robust loop finish the job, and how many write calls total if each subsequent call writes 90 bytes?

Forecast: how many bytes remain after the first call, and how many total calls?

After call 1: total = 120, remaining = 300 - 120 = 180. Next write starts at buf + 120 for count - total = 180 bytes. Why this step? You must resume from the unwritten part of the buffer — never rewrite from buf.
Call 2: writes 90 → total = 210, remaining 90.
Call 3: writes 90 → total = 300, remaining 0 → loop exits. Why this step? The loop condition total < count becomes false only when everything is out.
Total calls = 3 (120 + 90 + 90 = 300). Why this step? Production code never assumes one write suffices — a signal or full pipe can chop any call short.

Verify: 120 + 90 + 90 = 300 = count, and \lceil the arithmetic \rceil gives exactly 3 non-error calls. ✔

Example 6 — `open` on a missing file (cell I, G)

Worked example Statement

The file ghost.txt does not exist. Compare open("ghost.txt", O_WRONLY) versus open("ghost.txt", O_WRONLY | O_CREAT, 0644).

Forecast: which returns -1?

Without O_CREAT: the kernel walks the path, finds no inode, and returns -1 with errno = ENOENT ("No such file"). No file is made. Why this step? O_WRONLY declares intent to write, not permission to create. Creation is a separate flag.
With O_CREAT: the missing file is created with permission bits 0644 (owner read/write, others read), and a valid fd (smallest unused, e.g. 3) is returned. Why this step? The mode argument (0644) is consulted only when O_CREAT actually creates the file.
Handling the -1: always branch on the return value before using the fd; using -1 as an fd in read/write is itself an error (cell G). Why this step? A failed open gives you no valid handle — proceeding corrupts everything downstream.

Verify: first form → -1; second form → \geq 0. The convention "smallest unused fd" means with 0/1/2 taken by stdin/stdout/stderr, a fresh fd is 3. ✔

Example 7 — leaking fds until exhaustion (cell J, limiting value)

Count the used slots. fds 0,1,2 are stdin/stdout/stderr → 3 used, 1024 - 3 = 1021 free. Why this step? The limit counts all open descriptors, including the three inherited ones.

Each open consumes one slot (returns 3, then 4, 5, … 1023). After 1021 successful opens the table is full. Why this step? Without close, the reference count never drops, so slots are never returned.

The next (1022nd) open fails with -1, errno = EMFILE ("Too many open files"). Why this step? This is why leaking descriptors eventually breaks a long-running server — see ulimit and resource limits.

Verify: successful opens = 1024 - 3 = 1021; the 1022nd fails. ✔ Highest fd handed out = 1023 (the last free index). ✔

Example 8 — concurrent append logging (real world) (cell K)

Worked example Statement

Two processes both open log.txt with O_WRONLY | O_CREAT | O_APPEND and each write an 8-byte line "started\n". The file was empty. What are the two lines' byte offsets, and can they clobber each other?

Forecast: do the writes overlap?

O_APPEND semantics. Each write atomically seeks to the current EOF, then writes. The seek+write is one indivisible step from the kernel's view. Why this step? Atomicity is exactly what stops two writers from choosing the same offset.
Process P1 writes first (say): EOF is 0 → writes bytes 0–7, EOF becomes 8.
Process P2 writes: EOF is now 8 → writes bytes 8–15, EOF becomes 16. Why this step? Because the seek-to-EOF happens inside each atomic write, P2 can never land back on 0.
Final size = 8 + 8 = 16 bytes, two clean lines.

Verify: total bytes = 16, offsets [0,8) and [8,16) are disjoint (no overlap) regardless of ordering. ✔ Without O_APPEND, both could seek to 0 and produce an 8-byte clobbered file — the bug this flag prevents. ✔

Example 9 — exam twist: mixed `SEEK_CUR` with `O_APPEND` (cell L)

Worked example Statement

A 50-byte file opened O_RDWR (no append). You do: lseek(fd, 10, SEEK_SET), read(fd, buf, 5), then lseek(fd, -3, SEEK_CUR). What is the final offset?

Forecast: track the bookmark through all three steps.

lseek(fd, 10, SEEK_SET): offset = 10 (absolute). Why this step? Establish a known starting bookmark.
read(..., 5): reads bytes 10–14, offset advances 10 + 5 = 15. Why this step? read moves the bookmark by its return value (5, since 5 < 50).
lseek(fd, -3, SEEK_CUR): origin is current offset 15 → newpos = 15 + (-3) = 12. Why this step? SEEK_CUR with a negative offset rewinds relative to where you now are, not the file start.
Final offset = 12.

Verify: chain = 10 \xrightarrow{+5} 15 \xrightarrow{-3} 12, and 0 \leq 12 \leq 50. ✔ (Note: had the file been O_APPEND, the read offset would still work, but writes would ignore this bookmark and jump to EOF — a classic trap.) ✔

Case-coverage check

Recall Did we hit every matrix cell?

A ::: Example 1 (SEEK_SET forward) B ::: Example 2 (SEEK_END negative, incl. invalid -25) C ::: Example 3 (seek past EOF → sparse hole) D ::: Examples 1 & 2 (offset at boundaries 0 / size) E ::: Example 4 (short read, n < count) F ::: Example 4 (read returns 0 = EOF) G ::: Examples 6 & 7 (return -1, errno set) H ::: Example 5 (short-write loop) I ::: Example 6 (missing file, no O_CREAT → ENOENT) J ::: Example 7 (fd exhaustion → EMFILE) K ::: Example 8 (concurrent O_APPEND logging) L ::: Example 9 (mixed SEEK_CUR arithmetic)

Prerequisites you may want open alongside this page: System calls and the kernel boundary, File descriptor table, File system & inodes, and for the buffered contrast Buffered I/O (fopen/fread). The concurrency example connects to Pipes and sockets (where short reads are the norm, not the exception).