§39.1–39.4Files, Directories, and the Basic Interface

We have virtualized the CPU (the process) and memory (the address space). Now the third pillar: persistent storage — where users keep the data they actually care about, on a device that (unlike memory) survives power loss. This interlude covers the interface; later chapters build the implementation.

39.1 Files And Directories

Two abstractions organize storage. The first is the file file The file-system abstraction for a linear array of bytes you can read and write. The OS usually knows nothing about a file's contents; its job is to store the bytes persistently and return them intact. Each file also has a low-level name (its inode number). defined in ch. 39 — open in glossary : a linear array of bytes you can read or write. The OS mostly doesn’t care what those bytes mean (C code, a photo, text) — its job is to store them persistently and hand back exactly what you put in. Every file also has a low-level name, a number called its inode number inode number A file's low-level name: a unique number (also called an i-number) the file system uses internally to identify a file, as opposed to the human-readable name stored in a directory. A directory entry maps a name to an inode number. defined in ch. 39 — open in glossary (you’ll meet inodes properly later).

The second is the directory directory A special file whose contents are a list of (user-readable name, low-level name/inode-number) pairs. Each entry maps a name to either a file or another directory; nesting directories builds the directory tree. A directory has its own inode number and always contains '.' (itself) and '..' (its parent). You never write a directory directly — the file system owns its format. defined in ch. 39 — open in glossary . A directory also has an inode number, but its contents are specific: a list of (user-readable name, inode number) pairs. A directory named foo holding a file with low-level name 10 and readable name “foo” contains the entry ("foo", 10). Because each entry can point to a file or another directory, nesting them builds a directory tree directory tree The single hierarchy (a.k.a. directory hierarchy) into which all files and directories are organized, starting at the root directory '/'. A name like /foo/bar.txt is an absolute pathname walking the tree from the root. defined in ch. 39 — open in glossary rooted at /. Any file is then named by an absolute pathname absolute pathname A name that locates a file or directory by walking the directory tree from the root, e.g. /foo/bar.txt. Directories and files can share a name if they sit at different places in the tree. defined in ch. 39 — open in glossary that walks the tree from the root:

Valid directories above: /, /foo, /bar, /bar/bar, /bar/foo. Valid files: /foo/bar.txt and /bar/foo/bar.txt. Note the two different files both named bar.txt — same name, different places in the tree, no conflict. (The .txt is just convention; nothing enforces that main.c holds C.)

39.2–39.3 Creating Files

The interface starts with creating, accessing, and deleting files — including the mysteriously-named call to remove a file, which we’ll demystify at the end of the chapter. To create a file you call open() with the O_CREAT flag:

int fd = open("foo", O_CREAT | O_WRONLY | O_TRUNC, S_IRUSR | S_IWUSR);

Those flags say: create the file if it doesn’t exist (O_CREAT), allow only writing (O_WRONLY), and if it already exists truncate it to zero bytes (O_TRUNC). The third argument sets permissions (here, owner read+write).

What open() returns is the key: a file descriptor file descriptor A small non-negative integer, private per process, returned by open() and used to read/write a file. It indexes a per-process array of pointers into the open file table. Think of it as a capability — an opaque handle granting access. Descriptors 0, 1, 2 are stdin, stdout, stderr, so the first opened file is usually 3. defined in ch. 39 — open in glossary — a small integer, private to the process, that you then use to read or write the file. It is a capability: an opaque handle granting you the power to act on that file. The OS keeps them per process, in a simple array in the process structure (from the xv6 kernel):

struct proc {
  ...
  struct file *ofile[NOFILE]; // open files, indexed by descriptor
  ...
};

39.4 Reading And Writing Files

How does a program actually touch a file? The tool strace traces every system call a program makes. Run it on cat foo (after echo hello > foo) and step through what happens:

Two things to notice. First, why does the file open as descriptor 3? Every process starts with three descriptors already open: standard input (0), standard output (1), and standard error (2). So the next open lands on 3. Second, read() returns the number of bytes read — 6 for “hello\n” — and a later read() returning 0 signals end-of-file. Writing works the same way: open() (for writing), one or more write()s, then close().