13 The File System Sure It Corrupts Your Files, But Look How Fast It Is! Pretty daring of you to be storing important files on a Unix system. —Robert E. Seastrom The traditional Unix file system is a grotesque hack that, over the years, has been enshrined as a “standard” by virtue of its widespread use. Indeed, after years of indoctrination and brainwashing, people now accept Unix’s flaws as desired features. It’s like a cancer victim’s immune system enshrining the carcinoma cell as ideal because the body is so good at mak- ing them. Way back in the chapter “Welcome, New User” we started a list of what’s wrong with the Unix file systems. For users, we wrote, the the most obvi- ous failing is that the file systems don’t have version numbers and Unix doesn’t have an “undelete” capability—two faults that combine like sodium and water in the hands of most users. But the real faults of Unix file systems run far deeper than these two miss- ing features. The faults are not faults of execution, but of ideology. With Unix, we often are told that “everything is a file.” Thus, it’s not surprising that many of Unix’s fundamental faults lie with the file system as well.

262 The File System What’s a File System? A file system is the part of a computer’s operating system that manages file storage on mass-storage devices such as floppy disks and hard drives. Each piece of information has a name, called the filename, and a unique place (we hope) on the hard disk. The file system’s duty is to translate names such as /etc/passwd into locations on the disk such as “block 32156 of hard disk #2.”' It also supports the reading and writing of a file’s blocks. Although conceptually a separable part of the operating system, in practice, nearly every operating system in use today comes with its own peculiar file system. Meet the Relatives In the past two decades, the evil stepmother Unix has spawned not one, not two, but four different file systems. These step-systems all behave slightly differently when running the same program under the same circumstances. The seminal Unix File System (UFS), the eldest half-sister, was sired in the early 1970s by the original Unix team at Bell Labs. Its most salient fea- ture was its freewheeling conventions for filenames: it imposed no restric- tions on the characters in a filename other than disallowing the slash character (“/”) and the ASCII NUL. As a result, filenames could contain a multitude of unprintable and (and untypable) characters, a “feature” often exploited for its applications to “security.” Oh, UFS also limited filenames to 14 characters in length. The Berkeley Fast (and loose) File System (FFS) was a genetic make- over of UFS engineered at the University of California at Berkeley. It wasn’t fast, but it was faster than the UFS it replaced, much in the same way that a turtle is faster than a slug. Berkeley actually made a variety of legitimate, practical improvements to the UFS. Most importantly, FFS eliminated UFS’s infamous 14-character filename limit. It introduced a variety of new and incompatible features. Foremost among these was symbolic links—entries in the file system that could point to other files, directories, devices, or whatnot. Nevertheless, Berkeley’s “fixes” would have been great had they been back-propagated to Bell Labs. But in a classic example of Not Invented Here, AT&T refused Berkeley’s new code, leading to two increasingly divergent file systems with a whole host of mutually incompatiable file semantics. Throughout the 1980s, some “standard” Unix programs knew that filenames could be longer than 14 characters, others didn’t. Some knew that a “file” in the file