Lecture 3: Directories and Links

Note: Reading these lecture notes is not a substitute for watching the lecture. I frequently go off script, and you are responsible for understanding everything I talk about in lecture unless I specify otherwise.

Filenames and paths

If you needed to remember the inumber (inode index) for every file on your computer, that would be tragic. We could add a filename field to the inode, and then search through the inodes to find a matching file whenever we want something. However, this turns out to work poorly. In order to minimize the size of the metadata portion of the disk, we need to keep the inodes small, which means the maximum filename would need to be short. In order to keep things organized, humans tend to generate fairly long file paths; the file I’m currently editing has a file path of /Users/reberhardt/Documents/Stanford/Summer CS 110/www/content/lecture-notes/lecture-03.md. That path is 91 characters (91 bytes) – triple the current size of an inode. Additionally, performance quickly degrades if you need to search every inode for the file you’re looking for. My computer currently has 83,705,333 inodes in use, and it would be bad if I had to search every one of them every time I wanted to access a file.

The solution is to implement directories. You may be surprised to find that this requires almost no changes to our existing scheme; we can layer directories on top of the file abstraction we already have. In almost all filesystems (unix v6 included), directories are just files, the same as any other file (with the exception that they are marked as directories by the file type field in the inode). The contents of these files is a series of 16-byte slivers that form a table mapping filenames to inumbers.

Have a look at the contents of block 1024 (i.e. the contents of file with inumber 1) in the diagram above. This directory contains two files, so its total file size is 32; the first 16 bytes form the first row of the table (14 bytes for the filename, 2 for the inumber), and the second 16 bytes form the second row of the table. When we are looking for a file in the directory, we search this table for the corresponding inumber.

What does the file lookup process look like, then? Consider a file at /usr/class/cs110/example.txt. First, we find the inode for the file / (which always has inumber 1). In the table from that file’s contents, we look up the token usr. Let’s say it’s at inode 5. Then, we get file 5’s contents and look up the token class. From there, we look up the token cs110, and, finally, the token example.txt.

Directory details: . and ..

In Unix, there are some features of pathnames that you may have seen before: a leading / refers to the root directory, a leading ~ refers to your home directory, . refers to the current directory, and .. refers to the parent directory. (As an example, ~/./Desktop/../ refers to your home directory.)

As it turns out, . and .. are actually implemented as features of the filesystem. Every directory has at least two entries: an entry mapping . to the directory’s own inumber, and an entry mapping .. to the parent directory’s inumber.

Even the root directory has such entries. In the root directory’s case, however, both . and .. resolve to inumber 1 (i.e. the parent of the root directory is still the root directory).

Filesystems also generally support links, which are references to other files in the filesystem.

We have been talking about hard links throughout our entire discussion of directories, though you may not have known it. A hard link is simply an entry in a directory file. (We’ve been using the term “directory entry” and will continue to do so, but hard links are functionally the same thing.) Every file has at least one hard link pointing to it (i.e. the link in its parent directory). Every directory has at least two hard links pointing to it: the link in its parent directory, and its own . directory entry.

While hard links map filenames to inumbers, soft links map filenames to other filenames. (Soft links are also called symbolic links, because they resolve to symbolic names instead of numbers.) Just like directories are just files, symbolic links are also just files. When a symbolic link is created, a new file is created, but instead of having type “regular file” or “directory,” it has type “link.” The contents of this file is the path to the file it links to.