File System Architecture

All file systems that the BeOS recognizes are organized hierarchically. Most file systems use hierarchical organization naturally; any other type of organization must be adapted at the "file system handler" level to simulate a hierarchy (in order to be recognized by the BeOS). The result is that all file systems can be treated similarly in terms of their organizational architecture.

Hierarchical Organization

The tenets of a Be-recognized hierarchical file system are these:

In the BeOS, more than one file system can be mounted at a time. Each distinct file system is mounted within the root file system (described in the next section). Because of this, all (non-root) file systems maintain distinct boundaries. However, these otherwise-tidy boundaries are smudged a bit by…

Symbolic Links

The BeOS recognizes symbolic links. A symbolic link (or "symlink") is a file that "points to" some other entry (another file, directory, or symbolic link). The pointed-to entry can live anywhere—in some other directory, or even in another file system. Because of symbolic links, the graph of the hierarchy isn't acyclic: As you follow a path through the hierarchy, it's possible to get into a loop. (If you leave symbolic links out of the picture, the graph is acyclic.)


Currently, the BeOS does not recognize hard links (although it will in the future). A hard link associates an entry in the hierarchy with a specific chunk of data (a node). The attraction of hard links is that more than one entry can be associated with the same node.

File System Layout and the Root File System

Before looking at the file system layout, let's get one thing clear. The term "file system" is a heavily loaded monicker:

In the BeOS, this über-system is part of the kernel. The first thing it does is mount the root file system. All other file systems are mounted within the root file system.

The structure of the root file system is a simple, two-level hierarchy:

Directories at Root

The directories in the root file system have a prescribed purpose:

  • The directories are mount points for other file systems. A mount point becomes the root directory for the file system that's mounted there. (More accurately, the name of the mount point becomes the name of the root directory; the mount point directory itself is "obscured" when a file system is mounted on it.)

  • You can create your own directories in the root file system, but they can only be used as mount points—you can't use them to store files.

Symlinks at Root

The symlinks in the root file system are less restricted. The OS creates some number of symlinks automatically (as described below), but other than that, you're free to put whatever symlinks you want in the root file system. However, root level symlinks are simply a convenience for developers—the user won't be able to see them since the Tracker doesn't display the root file system.

Default Root Nodes

When BeOS is launched, some number of directories and symlinks are automatically created in the root file system. The directories are:

  • For each "persistent" file system that the OS finds (hard disks, CD-ROM, floppy, etc.), a mount point directory is created and the file system is mounted. The mount point for the file system that was used to boot the OS is /boot; the other mount point names are taken from the storage devices themselves (if you name your floppy "fido", the floppy will be mounted at /fido).

  • The OS also creates two virtual file systems, mounted at /dev and /pipe. We'll look at virtual file systems later. Briefly, a virtual file system is one that only exists in memory—it has no persistent storage. (The root file system itself is a virtual file system.)

And the symlinks are:

  • A link is made from /boot_disk_name to /boot.

  • Links are made from /bin, /system, and /etc to similarly named subdirectories of /boot/beos.

  • Links are made from /var to /boot/var and from /tmp to /boot/var/tmp.

If you cd to / in a shell and list the files, you'll see something like this (where "MyDisk" is the name of the boot disk, and "fido" is a floppy):

l--------- 1 users 0 Jun 19 22:11 bin -> /boot/beos/bin
drwx------ 1 users 2048 Jun 19 21:58 boot
drwxr-x--- 1 users 0 Jun 19 22:11 dev
l--------- 1 users 0 Jun 19 22:11 etc -> /boot/beos/etc
drwxr-xr-x 1 users 2048 Jun 19 22:12 fido
l--------- 1 users 0 Jun 19 22:11 MyDisk -> /boot
drwxrwxrwx 1 users 0 Jun 19 22:11 pipe
l--------- 1 users 0 Jun 19 22:11 system -> /boot/beos/system
l--------- 1 users 0 Jun 19 22:11 tmp -> /boot/var/tmp
l--------- 1 users 0 Jun 19 22:11 var -> /boot/var

If you invoke df, you'll see the list of mounted file systems:

Mount Type Total Free Flags Device
---------------- -------- -------- -------- -------------------------------
/ rootfs 0 0 0
/dev devfs 0 0 0
/pipe pipefs 0 0 0
/boot bfs 532950 395715 70004 /dev/disk/scsi/050/0_2
/fido bfs 1440 904 70004 /dev/disk/floppy/raw

All file systems, both persistent and virtual, are displayed by df. The virtual file systems are the ones that have 0 size.

Navigating the File System

If your application needs to get to a well-defined watering hole (such as the directory where a user's preference settings are stored, or where apps are kept), use the symbolic pathname constants to the find_directory() function. The constants are listed in the "Constants" section of this chapter. find_directory() is documented at the end of BDirectory description.

Virtual File Systems

A virtual file system has no backing storage. The hierarchy that it represents is maintained in memory. When you shut down the OS, all virtual file systems disappear.

Currently, the BeOS provides three virtual file system handlers:

From the developer's perspective, a virtual file system isn't much different from a persistent file system: You can create a BVolume object to represent it, you can walk through it's hierarchy, look at its contents, and so on.

But virtual file systems are hidden from the Tracker user: The Tracker does not display virtual file systems, nor does it let the user form a query on a virtual file system.

File System Handlers

When the kernel attempts to mount a file system, if must first find a file system handler that understands the file system's format. In other words, the handler is an intermediary between the kernel and the bytes on a disk (for example).

All file system handlers are add-ons. The kernel loads the handler add-on that it needs, and talks to it through a set of well-defined functions. The advantage of this approach is that the kernel doesn't need to know about specific file systems, it only needs to know how to talk to the handlers.

Currently, you can't create your own file system handler. The handler API will be released sometime in the future.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.