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.
The tenets of a Be-recognized hierarchical file system are these:
Data is organized as a tree of directories and files.
Directories contain files.
Each file is a member of only one directory (at a time). The directory is said to be the file's "parent." Once hard links are supported (as explained below) the one-parent rule will no longer hold.
Similarly, each directory has a single parent (directory).
The hierarchy "fans out" from the file system's root directory. The root directory is the common ancestor for all files and directories in the hierarchy.
Every file and directory has a "leaf" name; leaf names must be unique within the containing directory.
The only illegal characters in a leaf name (in the Be File System) are "/" and NUL (the character with the numeric value 0x00). Also, every directory automatically contains entries named "." and "..".
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…
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.
Before looking at the file system layout, let's get one thing clear. The term "file system" is a heavily loaded monicker:
At the lowest level, it means a "file system format." Currently, the BeOS recognizes BFS, HFS (Macintosh), and ISO9660 (CD-ROM) file system formats (other file systems are being ported).
"File system" can also mean the agent that knows how to turn bytes on a disk (or even in memory, as described in "Virtual File Systems") into the sort of hierarchy that the OS wants to see. When you pop in a floppy, for example, a file system handler must wrangle the disk format to convert its contents into a recognized hierarchy. When we say that the BeOS recognizes HFS, we're really saying that we provide an HFS file system handler. See "File System Handlers" for more information.
Yet another meaning of "file system" is that part of the OS that manages and lays out all the file systems that are mounted. It's the über-system for all hierarchies.
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:
The root directory of the root file system is
/. This is the only
directory in the entire hierarchy that doesn't have a parent.
The nodes in the root file system are directories and symlinks only. In other words, the root file system contains no real files.
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.
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.
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.
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.
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:
rootfs handles the root file system (described above). The root file
system is mounted at /.
It's always the first file system to be
mounted, and provides mount points for all other file systems.
devfs is the handler for the device file system, mounted at
/dev.
This system contains entry points for access to hardware devices,
including hard disks, CD-ROMs, and so on.
pipefs is the handler for the pipe file system, mounted at
/pipe. A
"pipe" is a location through which the POSIX pipe mechanism reads and
writes data.
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.
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.
