Source: Operating Systems: Three Easy Pieces (OSTEP) — Chapter 39, Arpaci-Dusseau & Arpaci-Dusseau
Interlude: Files and Directories
Processes virtualize the CPU; address spaces virtualize memory. Persistence adds the third piece: durable storage that survives power loss.
Crux: how should the OS manage a persistent device — APIs and key implementation ideas?
Files and directories
| Abstraction | Meaning |
|---|---|
| File | Linear array of bytes; low-level name = inode number |
| Directory | List of (user-readable name, inode #) pairs |
Directories nest into a tree rooted at /. Absolute path: /foo/bar.txt. Extensions (.c, .jpg) are convention — the FS usually does not enforce type.
UNIX routes almost everything through the tree (devices, pipes, /proc). Uniform naming simplifies the system [SK09].
Creating, reading, writing
open(path, O_CREAT|O_WRONLY|O_TRUNC, …)→ file descriptor (per-process capability).creat()≈ that flag combo (“I’d spell creat with an e” — Thompson).- FDs 0 / 1 / 2 = stdin / stdout / stderr; the next open is often 3.
read/write/close. Trace withstrace(ordtruss/truss).- Current offset lives in a system-wide open file table entry (
struct file:off,ip,readable/writable,ref).read/writeadvance it;lseeksets it — that call does not move the disk head by itself.
Two opens of the same file → two OFT entries (independent offsets). fork and dup/dup2 share one OFT entry (refcnt++) — useful for shells and cooperating writers.
Durability and rename
write() may only dirty page cache. fsync(fd) forces that file’s dirty data to disk; for a new file you may also need to fsync the parent directory [P+13,P+14].
rename(old, new) is typically crash-atomic (ends as old or new name). Editors often: write temp → fsync → rename over the real path.
Rank the sequence
1 / 1Order the steps of the atomic-update pattern editors use to safely replace a file (top = first).
OrderDrag the handle to rearrange — top should be first.
- 1Write the new content to a temp file
- 2fsync() the temp file’s dirty data to disk
- 3Create the temp file
- 4rename() the temp file over the real path
Drag items into the correct order (or use ↑↓), then check.
Metadata, directories, deletion
stat / fstat fill size, inode #, nlink, times, mode, … — kept in on-disk inodes (cached when active).
mkdir/rmdir(directory must be empty: only.and..)opendir/readdir/closedir(never write directory bytes directly)- Deleting a file is
unlink(name)— not “delete”
Hard links and symbolic links
Hard link (link / ln): another directory entry → same inode; bump link count. unlink removes one name; free inode+blocks when count hits 0. Limits: no directory hard links (cycles); no cross-FS links (inode #s are per FS).
Symbolic (soft) link (ln -s): a special file holding a pathname. Can dangle; can cross mounts and name directories.
Permissions, mount, TOCTTOU
Classic bits: rwx for owner / group / other (chmod). Execute on files = run; on directories = traverse/cd (with write to create). Richer systems use ACLs. Superuser/root (or admin groups) can bypass — a trust/security hotspot.
mkfs writes an empty FS onto a partition; mount pastes it at a mount point into one unified tree.
Time-of-check to time-of-use races (e.g. lstat then open) let attackers swap paths under privileged services [BD96]. Reduce root services; O_NOFOLLOW; careful privileged code.
Interactive
Try: abstractions · open/offset · hard vs soft links · permissions/mount.
Check your understanding
Files and directories
1 / 6A directory stores…
Pick an answer to see if you are right.
Coding challenges
Homework lab: FS API practice
Write small UNIX utilities from the chapter homework (no OSTEP simulator tarball for Ch. 39).
Homework: files API
0/4 startedSummary
| Piece | Role |
|---|---|
| File / inode | Persistent byte array + metadata |
| Directory | Name → inode map; . / .. |
| fd → OFT → inode | Offset and access rights |
| unlink / link / symlink | Names vs data lifetime |
| fsync / rename | Durability and atomic replace |
| mount | One namespace from many FSes |
Previous: RAID
Next: File System Implementation — vsfs on-disk structures and access paths.
Further Reading
- Remzi & Andrea Arpaci-Dusseau — Operating Systems: Three Easy Pieces Ch. 39
- OSTEP file-intro PDF
- Stevens & Rago [SR05]; Pillai et al. on crash-consistent apps [P+14]; Bishop & Dilger TOCTTOU [BD96]