haiku-website/static/legacy-docs/bebook/TheStorageKit_Overview_File...

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Be Book - System Overview - The Storage Kit</title><link rel="stylesheet" href="be_book.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
    <link rel="stylesheet" type="text/css" href="be_book_ie.css" />
    <![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><meta name="keywords" content="Access, BeOS, BeBook, API" /><link rel="start" href="index.html" title="The Be Book" /><link rel="up" href="TheStorageKit_Overview.html" title="The Storage Kit" /><link rel="prev" href="TheStorageKit_Overview_Introduction.html" title="Introduction" /><link rel="next" href="TheStorageKit_Overview_Entries_And_Nodes.html" title="Entries And Nodes" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="TheStorageKit_Overview_Introduction.html" title="Introduction"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="TheStorageKit_Overview.html" title="The Storage Kit"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="TheStorageKit_Overview_Entries_And_Nodes.html" title="Entries And Nodes"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="navigindex"><a accesskey="i" href="ClassIndex.html" title="Index">I</a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">The Be Book - System Overview - The Storage Kit</div></div><div id="headerB">Prev: <a href="TheStorageKit_Overview_Introduction.html">Introduction</a>  Up: <a href="TheStorageKit_Overview.html">The Storage Kit</a>  Next: <a href="TheStorageKit_Overview_Entries_And_Nodes.html">Entries And Nodes</a></div><hr /></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="TheStorageKit_Overview_FileSystemArchitecture"></a>File System Architecture</h2></div></div></div><p>
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.
</p><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><hr /><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Hierarchical_Organization"></a>Hierarchical Organization</h3></div></div></div><p>
The tenets of a Be-recognized hierarchical file system are these:
</p><ul class="itemizedlist"><li><p>
Data is organized as a tree of directories and files.
</p></li><li><p>
Directories contain files.
</p></li><li><p>
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.
</p></li><li><p>
Similarly, each directory has a single parent (directory).
</p></li><li><p>
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.
</p></li><li><p>
Every file and directory has a "leaf" name; leaf names must be unique
within the containing directory.
</p></li><li><p>
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 "..".
</p></li></ul><p>
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…
</p><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Symbolic_Links"></a>Symbolic Links</h4></div></div></div><p>
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.)
</p><div class="admonition warning"><div class="title">Warning</div><div class="graphic"><img class="icon" alt="Warning" width="32" src="./images/admonitions/Stop_32.png" /><div class="text"><p>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.</p></div></div></div></div></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><hr /><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_File_System_Layout"></a>File System Layout and the Root File System</h3></div></div></div><p>
Before looking at the file system layout, let's get one thing clear. The
term "file system" is a heavily loaded monicker:
</p><ul class="itemizedlist"><li><p>
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).
</p></li><li><p>
"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 "<a class="xref" href="TheStorageKit_Overview_FileSystemArchitecture.html#FileSystemArchitecture_File_System_Handlers" title="File System Handlers">File System Handlers</a>"
for more information.
</p></li><li><p>
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.
</p></li></ul><p>
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.
</p><p>
The structure of the root file system is a simple, two-level hierarchy:
</p><ul class="itemizedlist"><li><p>
The root directory of the root file system is
<code class="filename">/</code>. This is the only
directory in the entire hierarchy that doesn't have a parent.
</p></li><li><p>
The nodes in the root file system are directories and symlinks only.
In other words, the root file system contains no real files.
</p></li></ul><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Directories_At_Root"></a>Directories at Root</h4></div></div></div><p>
The directories in the root file system have a prescribed purpose:
</p><ul class="itemizedlist"><li><p>
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.)
</p></li><li><p>
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.
</p></li></ul></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Symlinks_At_Root"></a>Symlinks at Root</h4></div></div></div><p>
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.
</p></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Default_Root_Nodes"></a>Default Root Nodes</h4></div></div></div><p>
When BeOS is launched, some number of directories and symlinks are
automatically created in the root file system. The directories are:
</p><ul class="itemizedlist"><li><p>
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 <code class="filename">/boot</code>; the other mount point names are taken from the
storage devices themselves (if you name your floppy "fido", the floppy
will be mounted at <code class="filename">/fido</code>).
</p></li><li><p>
The OS also creates two virtual file systems, mounted at
<code class="filename">/dev</code> and
<code class="filename">/pipe</code>. 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.)
</p></li></ul><p>
And the symlinks are:
</p><ul class="itemizedlist"><li><p>
A link is made from <code class="filename">/boot_disk_name</code>
to <code class="filename">/boot</code>.
</p></li><li><p>
Links are made from
<code class="filename">/bin</code>,
<code class="filename">/system</code>, and
<code class="filename">/etc</code> to similarly named
subdirectories of <code class="filename">/boot/beos</code>.
</p></li><li><p>
Links are made from
<code class="filename">/var</code> to
<code class="filename">/boot/var</code> and from
<code class="filename">/tmp</code> to
<code class="filename">/boot/var/tmp</code>.
</p></li></ul><p>
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):
</p><pre class="screen">
l--------- 1 users 0 Jun 19 22:11 bin -&gt; /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 -&gt; /boot/beos/etc
drwxr-xr-x 1 users 2048 Jun 19 22:12 fido
l--------- 1 users 0 Jun 19 22:11 MyDisk -&gt; /boot
drwxrwxrwx 1 users 0 Jun 19 22:11 pipe
l--------- 1 users 0 Jun 19 22:11 system -&gt; /boot/beos/system
l--------- 1 users 0 Jun 19 22:11 tmp -&gt; /boot/var/tmp
l--------- 1 users 0 Jun 19 22:11 var -&gt; /boot/var
</pre><p>
If you invoke <code class="command">df</code>, you'll see the list of mounted file systems:
</p><pre class="screen">
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
</pre><p>
All file systems, both persistent and virtual, are displayed by <span class="application">df</span>. The
virtual file systems are the ones that have 0 size.
</p></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Navigating_The_File_System"></a>Navigating the File System</h4></div></div></div><p>
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
<a class="link" href="BDirectory.html#find_directory" title="find_directory()"><code class="function">find_directory()</code></a>
function. The constants are listed in the "<a class="xref" href="TheStorageKit_Constants.html" title="Constants">Constants</a>"
section of this chapter.
<a class="link" href="BDirectory.html#find_directory" title="find_directory()"><code class="function">find_directory()</code></a> is
documented at the end of
<a class="link" href="BDirectory.html" title="BDirectory"><code class="classname">BDirectory</code></a> description.
</p></div></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><hr /><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_Virtual_File_Systems"></a>Virtual File Systems</h3></div></div></div><p>
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.
</p><p>
Currently, the BeOS provides three virtual file system handlers:
</p><ul class="itemizedlist"><li><p>
rootfs handles the root file system (described above). The root file
system is mounted at <code class="filename">/</code>.
It's always the first file system to be
mounted, and provides mount points for all other file systems.
</p></li><li><p>
devfs is the handler for the device file system, mounted at
<code class="filename">/dev</code>.
This system contains entry points for access to hardware devices,
including hard disks, CD-ROMs, and so on.
</p></li><li><p>
pipefs is the handler for the pipe file system, mounted at
<code class="filename">/pipe</code>. A
"pipe" is a location through which the POSIX pipe mechanism reads and
writes data.
</p></li></ul><p>
From the developer's perspective, a virtual file system isn't much
different from a persistent file system: You can create a
<a class="link" href="BVolume.html" title="BVolume"><code class="classname">BVolume</code></a> object
to represent it, you can walk through it's hierarchy, look at its
contents, and so on.
</p><p>
But virtual file systems are hidden from the <span class="application">Tracker</span>
user: The <span class="application">Tracker</span>
does not display virtual file systems, nor does it let the user form a
query on a virtual file system.
</p></div><div class="section"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><hr /><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="FileSystemArchitecture_File_System_Handlers"></a>File System Handlers</h3></div></div></div><p>
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).
</p><p>
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.
</p><p>
Currently, you can't create your own file system handler. The handler API
will be released sometime in the future.
</p></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="TheStorageKit_Overview_Introduction.html">Introduction</a>  Up: <a href="TheStorageKit_Overview.html">The Storage Kit</a>  Next: <a href="TheStorageKit_Overview_Entries_And_Nodes.html">Entries And Nodes</a> </div><div id="footerB"><div id="footerBL"><a href="TheStorageKit_Overview_Introduction.html" title="Introduction"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="TheStorageKit_Overview.html" title="The Storage Kit"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="TheStorageKit_Overview_Entries_And_Nodes.html" title="Entries And Nodes"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
          <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
          Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>