Files and Directories

01 Introduction

Unit 9 closed with thrashing, the failure mode of virtual memory. This unit turns from memory to a different resource: persistent storage. A computer's memory is volatile — its contents are lost when the machine is powered off — but the data that users care about must survive across sessions, across reboots, and across the years. That data lives on secondary storage: magnetic disks, solid-state drives, and the network and cloud storage that sits behind them. And the way it is organised on that storage is the file system.

The file system is the operating system's most visible abstraction to the user. Every program reads and writes files; every command-line session manipulates them; every graphical user interface presents them as icons and folders. The file system is what allows a user to think of their data as a set of named documents and photographs rather than as a collection of bytes on a disk, and it is what allows a program to open a file by name without knowing where on the disk its data is stored.

The file system rests on two central abstractions. The first is the file: a named, persistent sequence of bytes. A file hides the details of the storage device — the disk's sectors, the SSD's flash pages, the network's packet boundaries — behind a uniform interface: a file is a stream of bytes that can be read from the beginning, written to the end, or, with some file systems, modified at an arbitrary position. The second abstraction is the directory: a mapping from names to files. A directory organises files into a hierarchy, gives them human-readable names, and allows the file system to scale from a handful of files to billions.

This lesson presents both abstractions in detail. It defines the file and its attributes, presents the standard file operations, and surveys the types of files that a modern Unix-like system provides. It defines the directory and its operations, presents the classical directory structures from the single-level directory of early systems to the tree and graph structures of modern systems, and explains how path resolution works. It presents the distinction between hard links and symbolic links, the mechanisms for file sharing and protection, and the concept of mounting — the mechanism by which multiple file systems are combined into a single hierarchy. It closes with a tour of the Linux file-system hierarchy, which is the standard organisation for Unix-like systems and the basis for the specific file systems examined in the rest of the unit.

The lesson is the first of seven in Unit 10. The lessons that follow present file metadata (Lesson 10.2), inodes (Lesson 10.3), directory organization in detail (Lesson 10.4), file allocation (Lesson 10.5), journaling (Lesson 10.6), and modern file systems (Lesson 10.7). This lesson provides the vocabulary and the conceptual framework for those lessons; it is the foundation on which the rest of the unit builds.

02 Learning objectives

This lesson contributes to U10.1 and U10.2, and to course learning outcomes CLO1, CLO5, and CLO6.

03 Required reading

• Operating System Concepts — Chapter 13, Sections 13.1–13.3, File Concept, Access Methods, and Directory and Disk Structure. The standard treatment of file attributes, operations, types, access methods, and directory structures.
• OSTEP — Chapter 39, Files and Directories. The clearest available treatment of the file and directory abstractions from the programmer's perspective, with the POSIX interface presented through the system calls that implement it. OSTEP's treatment is the basis for the worked example in this lesson.
• Tanenbaum & Bos — Modern Operating Systems, Chapter 4, Sections 4.1–4.2, Files and Directories. A complementary treatment that develops the file abstraction from first principles, with the historical context of the single-level and two-level directory structures.
• Silberschatz et al. — Chapter 13, Sections 13.1–13.3, and Chapter 14, Sections 14.1–14.3, File-System Structure, File-System Implementation, and Directory Implementation. Read the discussion of directory implementation and the mounted file-system structure.
• Bryant, R. E., & O'Hallaron, D. R. — Computer Systems: A Programmer's Perspective, 3rd ed., Chapter 10, System-Level I/O. The programmer's view of files, file descriptors, and the Unix I/O interface.
• Kerrisk, M. — The Linux Programming Interface, Chapters 1–5 and 14–18. The definitive reference for the Linux file interface, including file descriptors, files and directories, file systems, and extended attributes.
• Filesystem Hierarchy Standard (FHS) — version 3.0. The specification of the standard Linux directory layout, available online.
• Linux man pages: man 7 path_resolution, man 7 symlink, man 2 open, man 2 read, man 2 write, man 2 close, man 2 lseek, man 2 stat, man 2 link, man 2 symlink, man 2 mkdir, man 2 rmdir, man 2 unlink, man 2 rename, man 2 chdir, man 2 getcwd, man 2 mount, man 3 readdir, man 7 hier, man 8 mount.

04 Core content

4.1 The file abstraction

A file is a named, persistent sequence of bytes managed by the operating system. The definition has three important parts.

• Named. A file has a human-readable name — report.txt, photo.jpg, main.c — which distinguishes it from every other file in its directory. The name is what the user types to refer to the file; the file system maintains a mapping from names to the file's storage.
• Persistent. A file's contents survive across the termination of the process that created them, across the closing of the file, across reboots, and across the lifetime of the operating system. This distinguishes files from the memory that a process uses: memory is volatile, files are not.
• Sequence of bytes. A file is a stream: a sequence of bytes with a defined order. Most files do not have an internal structure that the operating system knows about — a text file, an image, an executable, and a database table are all just sequences of bytes as far as the file system is concerned. The meaning of the bytes is provided by the programs that interpret them, not by the file system itself.

The abstraction is deliberately minimal. It says nothing about what the bytes mean, how they are stored, or how they are accessed. Those decisions are left to the applications, which allows the file system to be general and the storage device to be changed without requiring any changes to the applications.

4.2 File attributes

A file's attributes are the metadata associated with it: information about the file rather than the file's contents. The attributes vary between file systems, but the following are universal.

The attributes are stored in the file system's metadata structures, not in the file itself. On Unix, they live in the file's inode (Lesson 10.3), which is a separate data structure from the file's data blocks. This separation is fundamental: it allows the file system to look up a file's attributes without reading the file's contents, and it allows the file's contents to be stored anywhere on the disk without affecting how the file is located by name.

4.3 File operations

The standard operations that a file system provides are the same across almost every system. On POSIX, they are exposed through system calls.

open

Open an existing file (or create a new one) and return a file descriptor — a small integer that identifies the open file within the process. The file descriptor is the process's handle for subsequent operations. The open call takes a set of flags (read-only, write-only, read-write, create, truncate, append) that determine how the file may be used.

read

Read a specified number of bytes from the file into a buffer, starting at the current position and advancing the position by the number of bytes read. The call returns the number of bytes actually read, which may be less than requested (at end of file, or if the read was interrupted).

write

Write a specified number of bytes from a buffer to the file, starting at the current position and advancing the position. The call returns the number of bytes actually written.

lseek

Move the file's current position to a specified offset. Used for random access: reading or writing at an arbitrary position within the file, rather than sequentially.

close

Close the file and release its file descriptor. When a process terminates, the operating system closes all of its open files automatically.

unlink

Remove the file's directory entry. If no other hard links to the file exist and no process has it open, the file's data blocks are freed and the file ceases to exist. If other links exist or the file is open, only the name is removed; the file's contents persist until the last reference is gone.

rename

Change a file's name, or move it to a different directory. On POSIX, the operation is atomic: a reader either sees the old name or the new one, never an intermediate state.

truncate

Reduce a file's size to zero (or to a specified length), discarding the contents beyond the new length. The file's attributes are preserved; only its contents are removed.

The operations are collected in the open-file table, which is the operating system's record of the files that are currently open. On Unix, the table has two parts: a per-process table that maps file descriptors to entries in a system-wide table, and the system-wide table that holds the file's open state (its current position, its access mode, and a reference to the file's inode). The two-level structure allows multiple processes to share the same open file while maintaining independent file descriptors, which is what makes the fork semantics work: a child inherits its parent's file descriptors, and the two processes share the same open-file entries, including the current position.

The open and close operations exist for efficiency. If the file system had to look up the file's attributes on every read or write, the overhead would be prohibitive. By opening the file once and holding a file descriptor, the program amortises the lookup over many operations. The open call also performs the access-permission check once, rather than on every read or write, which simplifies the code and improves performance.

4.4 File types

Unix-like systems distinguish several kinds of file. Every file has a type, recorded in its metadata, that determines how it behaves.

The variety of file types reflects Unix's design philosophy: everything is a file. Devices, communication endpoints, and ordinary data are all presented through the same interface — the file descriptor — so that a program can read from a disk, a terminal, and a network connection using the same system calls. This uniformity simplifies programs enormously and is one of the reasons Unix-like systems have been so influential.

4.5 File access methods

The way a program accesses a file's contents is determined by the access method. The standard methods are:

• Sequential access. The file is read or written from beginning to end, in order. Each read or write advances the file's position by the number of bytes transferred. The classic example is a text file: a program reads it line by line, processing each line in order. Sequential access is the default on Unix-like systems and is what a program gets when it uses read and write without seeking.
• Direct (or random) access. The file is read or written at an arbitrary position, selected by the program. Each access specifies the position explicitly, and the file's internal order does not constrain the access order. The classic example is a database file: a program seeks to the record it wants, reads it, and seeks to the next record, which may be anywhere in the file. On Unix, direct access is provided through the lseek system call and through the pread and pwrite calls, which combine the seek and the read or write into a single operation.
• Indexed access. The file has an index that maps a key to a position, and the program accesses the file through the index. This is not a file-system feature in the classical Unix model — the file system does not know about the index — but it is provided by the program or by the file system on some systems (mainframe systems had native indexed files). On Unix, the index is typically maintained by the application, using a separate index file and the file system's direct access.

The distinction between sequential and direct access is important for the file system's implementation. A sequential access is the file system's ideal: it can read ahead (as in Lesson 9.4's demand paging) and optimise for the streaming access pattern. A direct access is more expensive, because the file system cannot predict where the next access will be and cannot prefetch. Most modern file systems therefore perform much better on sequential workloads than on random ones, and programs that can be structured to access files sequentially are usually much faster than programs that seek randomly.

4.6 The directory abstraction

A directory is a file that contains a mapping from names to files. It is the mechanism by which the file system provides human-readable names and organises files into a hierarchy.

The mapping is from a name (a string) to a file's identity (its metadata, typically an inode number). When a program asks the file system to open report.txt, the file system looks up the name in the current directory, obtains the inode number, and uses the inode number to find the file's metadata and data. The name is only an entry in the directory; the file itself is identified by its inode, which is independent of the name.

This separation between names and identity is central to the design of Unix file systems. It allows a single file to have multiple names (through hard links, as we will see in section 4.10), it allows a file to be renamed without affecting its identity, and it makes the file system's directory operations simple: adding a name is adding an entry, removing a name is removing an entry, and neither affects the file's contents.

4.7 Directory operations

The standard operations on a directory are the same across systems and mirror the operations on files, with the addition of operations specific to the name-to-file mapping.

mkdir

Create a new, empty directory. The new directory is added as an entry to an existing directory (its parent).

rmdir

Remove an empty directory. If the directory contains any files, the operation fails; the caller must remove the entries first or use a recursive delete. This restriction prevents accidental deletion of files by a single rmdir call.

opendir and readdir

Open a directory and read its entries one at a time. On Unix, the directory is read as a sequence of entries, each consisting of a name and an inode number. The order of the entries is unspecified; it is typically the order in which they are stored in the directory, which depends on the file system's internal structure (Lesson 10.4).

link and unlink

Add or remove a name-to-file mapping. The link call creates a new name for an existing file (a hard link); the unlink call removes a name. These are the operations that change the directory's contents without changing the files themselves.

rename

Change a file's name, or move it between directories. The rename operation is atomic on POSIX systems: a reader either sees the old state or the new one, never an intermediate state. This makes rename useful for atomic file updates: a program writes to a temporary file, then renames it over the original, so readers never see a half-written file.

chdir and getcwd

Change and query the process's current working directory (section 4.9). The working directory is the starting point for relative path resolution.

4.8 Directory structures

The file system's directory structure determines how files are organised and how the file system scales. The classical structures, in order of increasing complexity, are the following.

Single-level directory

All files are in a single directory. The structure is simple and easy to understand, but it has serious limitations. All file names must be unique, so a user cannot have two files with the same name (a common problem when two users submit files with the same name). As the number of files grows, the directory becomes unwieldy, and finding a file by name becomes slow. The single-level directory was used in early systems with a small number of files, but it does not scale.

Two-level directory

Each user has a separate directory, and the file system has a master directory containing one entry per user. The user's directory is a single-level directory containing the user's files. The structure solves the name-collision problem (two users can have files with the same name) and simplifies the file system's access control (a user's files are in one place). But it does not allow users to organise their own files into subdirectories, so a user with many files faces the same problem as the single-level directory.

Tree-structured directory

The directory hierarchy is a tree: each directory may contain files and subdirectories, and every file has a unique path from the root. The tree structure is the standard for modern file systems. It allows users to organise their files as they see fit, with as many levels of nesting as they need. It provides natural grouping (related files in the same directory) and natural paths (the sequence of directory names from the root). The tree has one important property: each file has a unique path, and the directory structure is acyclic. This simplifies the file system's algorithms but restricts the sharing of files between users (a file can only appear in one place).

Acyclic graph directory

The directory structure is a directed acyclic graph: a file or directory may have multiple parents, but the structure has no cycles. The structure is created by hard links (which add a new name for an existing file) and by symbolic links (which add a file whose contents are a path to another file). It allows sharing (a file can appear in multiple directories) without the complications of cycles. The acyclic graph is what most Unix-like file systems provide: the tree structure is the base, and hard and symbolic links extend it into a graph.

General graph directory

The directory structure may contain cycles: a directory may contain a reference to one of its ancestors, or to itself. The general graph allows arbitrary sharing and is what is used in some distributed file systems and in network file systems that mount remote directories into the local hierarchy. It has a significant drawback: operations that traverse the directory structure — a recursive delete, a recursive search, a disk-space accounting — must detect and handle cycles, which complicates the file system's implementation. Cycle detection requires either a visited-set or a count of visits, both of which are expensive. For this reason, cycles are avoided in most Unix-like file systems, and the acyclic graph is the structure that is actually provided.

4.9 Paths and path resolution

A file's location in the directory structure is given by its path: the sequence of directory names from the root to the file, with the names separated by a slash character (/). The path /home/alice/report.txt means: start at the root directory, find the entry for home, find the entry for alice in that directory, and find the entry for report.txt in that directory. The file is identified by that entry.

A path that starts with a slash is an absolute path: it begins at the root and its meaning does not depend on the process's context. A path that does not start with a slash is a relative path: it begins at the process's current working directory, a per-process attribute that can be changed with the chdir system call. The working directory is the process's context for path resolution; it is what allows a program to refer to files by short names (report.txt) without specifying the full path from the root.

The special entries . and .. are present in every directory. . refers to the directory itself, and .. refers to its parent. They allow relative paths to move up and down the hierarchy: ../sibling/file.txt refers to a file in the parent's sibling directory, and ./file.txt refers to a file in the current directory. These entries are created automatically when a directory is created, and they are maintained by the kernel.

Path resolution is the process by which the kernel converts a path into a reference to a file. The kernel starts at the root (for an absolute path) or the working directory (for a relative path), and it processes each component in turn:

1. The kernel looks up the current component's name in the current directory, obtaining the entry's inode number.
2. It reads the inode for that entry, checking that the entry is a directory (if there are further components to process) and that the process has execute permission on the directory.
3. If there are further components, the kernel descends into the directory: the current directory becomes the directory the inode refers to, and the kernel continues with the next component.
4. When all components have been processed, the kernel has a reference to the final file. It checks the process's permissions on the final file (read, write, or execute, according to the operation being performed) and either proceeds with the operation or returns an error.

The resolution can fail at any step: a name may not exist in the directory, a component may not be a directory, or the process may lack permission to search the directory. In each case the kernel returns an appropriate error (ENOENT for a missing file, ENOTDIR for a non-directory in the middle of a path, EACCES for a permission problem) and the operation fails. The path-resolution process is one of the most frequently executed in a Unix-like system: every file open, every stat, every directory change goes through it.

4.10 Hard links and symbolic links

Unix-like file systems provide two mechanisms for giving a file more than one name. They differ in how they relate to the underlying file.

Hard link

A hard link is a directory entry that refers to an existing file's inode. Creating a hard link adds a new name to the directory, pointing to the same inode as an existing file. The two names are equivalent: they refer to the same file, and the file's contents are shared. The file system tracks the number of hard links to a file (the link count), and the file is deleted only when the last link is removed. Hard links have two important restrictions. First, they cannot cross file-system boundaries, because an inode number is meaningful only within its own file system. Second, they cannot refer to a directory (except for the special . and .. entries), because allowing directory hard links would introduce cycles into the directory structure. Within these restrictions, hard links are the classical mechanism for sharing a file among multiple names, and the same file can appear in multiple directories on the same file system.

Symbolic link (soft link)

A symbolic link is a file whose contents are a pathname. It is an indirect reference: the link's pathname is resolved independently of the link itself, and the resolution may produce a different file each time. A symbolic link can cross file-system boundaries, because it stores a pathname rather than an inode number. It can refer to a directory, because the kernel does not create a cycle at the inode level. And it can be dangling: a symbolic link whose target does not exist is a valid file; the error occurs only when the link is dereferenced. The cost is that dereferencing a symbolic link requires extra work: the kernel must read the link's contents and resolve the path, which may itself involve more symbolic links (a chain) or even cycles (which the kernel detects by limiting the resolution depth).

The choice between hard and symbolic links depends on the requirements. A hard link is efficient (no additional resolution), it is indistinguishable from the original file (both names refer to the same inode), and it is the right choice when a file should have two equivalent names within the same file system. A symbolic link is more flexible (it can cross file-system boundaries, refer to directories, and dangle), it is visible (the link's target is stored as a pathname, and commands like ls -l show it explicitly), and it is the right choice when the reference should be indirect: for example, /usr/bin/cc is usually a symbolic link to the current default C compiler, and it is updated when the default changes.

The distinction between hard links and symbolic links also affects how the file system handles the deletion of a file. Deleting a hard link removes only that name; the file's contents are freed only when the link count reaches zero and no process has the file open. Deleting a symbolic link removes the link itself; the target file is unaffected. And creating a hard link is not possible if the target does not exist (the inode must exist); a symbolic link to a nonexistent file is perfectly legal.

4.11 File sharing and protection

On a multi-user system, files are shared among users and among processes. The file system must provide mechanisms for sharing while protecting files from unauthorised access.

The classical Unix protection mechanism is the permission bits. Each file has three sets of three bits:

• Owner permissions — the rights of the file's owner.
• Group permissions — the rights of the members of the file's group.
• Other permissions — the rights of everyone else.

Each set contains three bits: read, write, and execute. A file's permissions are written as a nine-bit string, or as three octal digits. For example, rwxr-xr-x (or 755) means the owner may read, write, and execute the file; the group may read and execute but not write; and others may read and execute but not write. The permission bits are checked by the kernel on every access, at the file's inode, and the check is what enforces the system's access-control policy.

Modern Unix-like systems also support access control lists (ACLs), which allow more fine-grained permissions: a file may be readable by one specific user, writable by another, and completely inaccessible to everyone else. ACLs are an extension of the classical permission model; a file with an ACL still has the classical permission bits, and the ACL is consulted only if the classical bits do not already permit the access. ACLs are used in systems that require finer-grained control than the classical model provides, and they are supported by most modern Unix file systems.

File sharing also has a per-process dimension. When a process opens a file, the kernel creates an entry in the process's file descriptor table that refers to an entry in the system-wide open-file table. The open-file table entry records the file's current position, access mode, and a reference to the file's inode. When a process forks, the child inherits the parent's file descriptor table, and the two processes share the same open-file table entries. This means that a read by the parent advances the file position for the child as well, and vice versa. The behaviour is what allows a shell pipeline to work: the shell forks a child for each command in the pipeline, and the children share their standard input and output, which are the connections between the commands.

4.12 Mounting and the file-system hierarchy

A modern system usually has several file systems: the root file system, a separate file system for /home, a separate file system for /var, a temporary file system for /tmp, and possibly several remote file systems mounted from other machines. The operating system combines them into a single, unified hierarchy through the process of mounting.

Mounting attaches a file system to a directory in an existing file system. The directory is called the mount point, and after the mount, the contents of the mounted file system appear at the mount point. A process that accesses /home after /home has been mounted sees the contents of the mounted file system, not the contents of the underlying directory on the root file system. The underlying directory is hidden — inaccessible — until the file system is unmounted.

The mount operation is implemented by the kernel, and its state is recorded in a mount table. On Linux, the mount table is visible in /proc/self/mounts (or /proc/mounts), and the mounts can be manipulated with the mount and umount commands (with root privileges). The mount table records, for each mount, the file system's type, the device that holds it, the mount point, and the mount options (read-only, no-execute, and so on).

Mounting is what allows Unix-like systems to present a single, uniform hierarchy even when the underlying storage is heterogeneous. The user sees one tree, rooted at /, and does not need to know that /home is on one disk and /var is on another, or that /mnt/backup is on a network server. This transparency is one of the reasons Unix-like systems are so convenient to use, and it is one of the reasons the mount mechanism has been copied by other operating systems.

The Linux file-system hierarchy is standardised by the Filesystem Hierarchy Standard (FHS), which specifies the purpose of each top-level directory. The standard layout includes:

The layout is not arbitrary. It separates files by their role: files that are essential for booting the system (in /bin, /lib, /etc), files that are installed by the system's package manager (in /usr), files that change as the system runs (in /var), and files that belong to users (in /home). The separation is designed to allow different directories to be stored on different file systems with different properties: /usr might be read-only (it changes only when software is installed), /var is writable and may be on a different disk, and /home may be on a network file server. The layout is one of the reasons a Unix-like system can be administered effectively even when its storage is distributed across many devices.

4.13 Common misconceptions

05 Worked example

The following example traces the resolution of an absolute path, compares the behaviour of hard and symbolic links, and computes the effect of the Unix permission bits on a file access.

$ ln /home/alice/report.txt /home/alice/report-copy.txt
$ ln -s /home/alice/report.txt /home/alice/report-link.txt

$ ls -li /home/alice/report*.txt
262147 -rw-r--r-- 2 alice alice 4096 ... report.txt
262147 -rw-r--r-- 2 alice alice 4096 ... report-copy.txt
262148 lrwxrwxrwx 1 alice alice   24 ... report-link.txt -> /home/alice/report.txt

$ rm /home/alice/report.txt
$ ls -li /home/alice/report*.txt
262147 -rw-r--r-- 1 alice alice 4096 ... report-copy.txt
262148 lrwxrwxrwx 1 alice alice   24 ... report-link.txt -> /home/alice/report.txt
$ cat /home/alice/report-copy.txt   # succeeds — the inode still has one link
$ cat /home/alice/report-link.txt   # fails — the target path no longer exists
cat: /home/alice/report-link.txt: No such file or directory

$ mount /dev/sdb1 /home
$ cat /proc/self/mounts | grep home
/dev/sdb1 /home ext4 rw,relatime 0 0

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• A file is a named, persistent sequence of bytes managed by the operating system. The abstraction hides the details of the storage device and presents a uniform interface for reading and writing.
• A file's attributes — name, identifier, type, location, size, protection, owner, and timestamps — are stored in the file system's metadata structures, not in the file itself. On Unix, the metadata lives in the file's inode.
• The standard file operations are open, read, write, lseek, close, unlink, rename, and truncate. The file descriptor is the process's handle for an open file, and the open-file table has a two-level structure that allows sharing among processes.
• Unix-like systems distinguish several file types: regular files, directories, symbolic links, character devices, block devices, FIFOs, and sockets. The variety reflects the principle that everything is a file: devices and communication endpoints are exposed through the same interface as ordinary data.
• The standard access methods are sequential (read or write from beginning to end), direct (read or write at an arbitrary position), and indexed (access through a key-based index). Sequential access is the default on Unix and is what the file system optimises for.
• A directory is a file that maps names to files. The separation of names from identity — names are directory entries, identity is the inode number — is central to the Unix file model. It allows multiple names for the same file, renames without affecting open file descriptors, and simple directory operations.
• The classical directory structures are single-level, two-level, tree, acyclic graph, and general graph. Modern Unix-like systems use the acyclic graph: the tree is the base, and hard and symbolic links extend it with sharing while the kernel prevents cycles.
• Path resolution converts a path into a reference to a file by processing each component in turn, checking permissions at each step. Absolute paths begin at the root; relative paths begin at the process's current working directory. The special entries . and .. refer to the current and parent directories.
• A hard link is a directory entry that refers to an existing file's inode. A symbolic link is a file whose contents are a pathname. Hard links cannot cross file-system boundaries or refer to directories; symbolic links can do both and can dangle. When the target is deleted, a hard link keeps the file alive, while a symbolic link becomes a dangling reference.
• File protection on Unix is provided by the permission bits — owner, group, and other, each with read, write, and execute — checked by the kernel at the file's inode. Modern systems also support access-control lists (ACLs) for finer-grained permissions.
• Mounting attaches a file system to a directory in an existing hierarchy, allowing a system with multiple file systems to present a single unified tree. The contents of the mount point directory are hidden while the file system is mounted.
• The Linux file-system hierarchy is standardised by the Filesystem Hierarchy Standard: the root, /bin, /boot, /dev, /etc, /home, /lib, /media, /mnt, /opt, /proc, /root, /sbin, /sys, /tmp, /usr, and /var. The layout separates files by role and allows different directories to be stored on different file systems.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 13, Sections 13.1–13.3, and Chapter 14, Sections 14.1–14.3.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapter 39. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 4, Sections 4.1–4.2.
• Bryant, R. E., & O'Hallaron, D. R. Computer Systems: A Programmer's Perspective, 3rd ed., Chapter 10, System-Level I/O.
• Kerrisk, M. The Linux Programming Interface. No Starch Press, 2010. Chapters 1–5 and 14–18. The definitive reference for the Linux file interface.
• Ritchie, D. M., & Thompson, K. The UNIX Time-Sharing System. Communications of the ACM, 1974. The paper that introduced the Unix file model, including the hierarchical directory structure and the "everything is a file" principle.
• McKusick, M. K., Joy, W. N., Leffler, S. J., & Fabry, R. S. A Fast File System for UNIX. ACM Transactions on Computer Systems, 1984. The paper that introduced the Berkeley Fast File System, which established many of the design principles still in use today.
• Filesystem Hierarchy Standard Group. Filesystem Hierarchy Standard (FHS) version 3.0. Available online. The specification of the standard Linux directory layout.
• Linux man-pages: man 7 path_resolution, man 7 symlink, man 7 hier, man 2 open, man 2 read, man 2 write, man 2 close, man 2
  👤
  📋0

  ← Discussion

  ＋ ✕

  This page Whole course
  🎥0

  Video call

  ✕

  Room

  Your name

  Test camera Join call

  Audio only

  🎤 🎥 🖥 📞
  📝0

  ← Assessments ✕

  This page Course My grades Marking queue
  💬

  Course Assistant

  🔎 👤 🗑 ✕

  Send