InformIT: Mac OS X Unleashed > The Unix File System

Table of Contents

The Unix File System

To the novice Unix user—especially one coming from a GUI environment as nice as the Mac's—venturing into the Unix file system will probably feel like a journey back to the Stone Age. Files upon files, nothing to indicate what any of them do, and not a friendly icon in sight. Although the file system might initially appear cryptic and primitive, you will find that with experience, it actually affords you considerable sophistication and control. This sophistication comes from the ability to combine the functions of many small programs into larger programs with arbitrarily complex functions.

Before the use of most Unix commands will make sense, you'll need to understand a few things about the design of the Unix file system. The Mac OS X HFS+ file system doesn't strictly adhere to the model that most Unixes use, but from the point of view of the BSD subsystem, it functions in an analogous manner. You'll find a number of differences between the way Unix thinks of files, and what you're probably used to, but after you get used to them, you'll probably find these differences are to your liking.

Basic Unix File Principles

Unix file systems have a single root directory. Unlike Macintosh file systems with their multiple drive icons on the desktop, and Windows machines with their ABCs, Unix file systems have only a single top-level designator for the file system. This is the root directory named /. Unix considers all its files to belong to a tree-shaped structure, with the root directory at its base and files as the leaves. Directories are the branching points between the branches. Unix trees are upside down with respect to real trees, as the root directory is at the top of the tree. Any directory can contain files and other directories.

Every file in the Unix file system has a unique and unambiguous name that points to it. This complete name is known as the "full path" to the file, and can be specified from any directory in the file system to indicate any file in the file system. The full path to a file always starts with the root directory, and ends in the filename, indicating directory names along the way, separated by the separator character /. A full path may be thought of as the shortest list of directories that must be traversed from the root to reach the file. A file with the full path /home/wizbot/spin/spinnin is named spinnin, and is located in the directory spin, which is located in the directory wizbot, which is located in the directory home, which is located in the root directory /.

Files have both full paths and relative paths. A relative path is a path from the current directory, instead of from the root directory. There are two special relative directory names. One of these is ., which indicates the current directory; the other is .., which indicates the directory that is the parent of this directory. For example, assume that there is a directory named spun in the same directory as the directory named spin in the earlier path (it would have a full path of /home/wizbot/spun). If we are in the directory spun and want to specify the relative path to spinnin, we can do so with the relative path ../spin/spinnin.

Not only don't you have multiple drives at the top level of the system, you, as the user, don't need to know what drives are where. Additional drives (or, more properly, partitions) appear as directories, and can be mounted at any point in the file system to appear as an extended branch in the system. Sound strange? After a while it won't. In one of the nice feats of Unix abstraction, the system removes from the user's sphere of concern what hardware devices actually exist, and where they are or how they're connected. After you get used to this system, you'll see that it makes good sense. So long as you can uniquely identify a file by name in the file system, why would you care which spinning chunk of metal it lives on? This system has additional nice features. If you find one day that you've run out of space to put files in some particular location, you can simply add a drive to the system and mount it where you need space. There's no need to reconfigure things or move files around, because the additional space will simply appear as new space in whatever directory you mount it as.

As a matter of fact, you don't even need to know what country your files physically reside in. Again, Unix abstraction comes into play, and a remote file server is mounted as a directory under the local file system just like additional physical storage is. From your point of view, a remote file server is just another directory; the only difference between accessing files on it and on local storage is the possible network delay associated with transporting the files.

Regardless of whether you know where your files actually are, the shell, as previously mentioned, is always somewhere in the file system structure.

Also as previously mentioned, Unix is a case-sensitive system, and Unix filenames are case sensitive from the command line. From OS X, this isn't necessarily the case (depending on which base disk format you chose for your installation), but when you're working from the command line, remember that what you type must have the correct capitalization.

A file has three attributes that control who can access the file. These attributes control access at the level of whether the file can be read, written to, and executed. Additionally, these attributes can be specified separately for the user who owns the file, a group of selected users, and everybody on the system. These attributes can be set to any combination of values, although some combinations do not make much sense. For example, you would expect an application to be executable, a configuration file for a program to be readable, and something like your daily schedule to be both readable and writeable.Unix, however, will do whatever you tell it to with the file permissions. If you make your daily schedule executable, Unix will do its best to execute it, which most likely will result in an error message and no damage done. If you tell Unix that an application is writeable, it will be happy to let you edit it in a word processor, which will probably make the application useless. We'll cover file permissions in more detail later in the "Introduction to File Permissions" section of Chapter 14.

Everything in the file system has an owner. Every file and directory in the Unix file system has auxiliary information attached to it that specifies the individual user who owns it, and also the group of users that owns it. Depending on the permissions, this user or group of users control access to the file and can set its permissions.

Each user has a home directory. This is one special directory in the file system that is owned by the user, and is used to contain configuration files and other content that is specific to the user. From the point of view of the file system, the user's home directory is no different than any other directory, but it is significant in that it is the directory where you start when you open a terminal and shell on the system. To make things simpler for you, Unix doesn't require that you remember the path to your directory; it can always be specified by the special full path ~ <username> .

Keep these basic principles in mind when reading about the commands to work within the file system. We'll cover some of them in more detail later in this chapter, but it will help you to have a basic understanding of them as we move to the explanations and examples of commands.

Basic File System Navigation | Next Section

Previous Section