Section 9.1. Mac OS X Filesystems

9.1. Mac OS X Filesystems

Like earlier versions of Mac OS, Mac OS X filesystems favor the Mac OS Extended Format , better known as HFS+ (Hierarchical File System), ^[*] but they also work well with the Universal File System (UFS ) that most other Unix-based operating systems use as their primary filesystem.

^[*] Mac OS 8.1 and later used HFS+, while versions prior to 8.1 used the older Mac OS Standard Format, known as just HFS (without the plus).

Most Mac OS X volumes use HFS+ as their format for two reasons. First, until Mac OS X 10.3, HFS+ has performed much better than UFS (though UFS performance in Tiger has improved greatly, close to matching that of HFS+). The other reason is that HFS+ natively supports multiple file forks (see the later section "File Forks".) Still, through strong UFS support, a Mac OS X machine can work seamlessly with other Unix volumes , such as network-mounted ones that may be accessible over NFS.

9.1.1. Differences Between HFS+ and UFS

Here are the most noticeable differences between the HFS+ and UFS file formats:

• UFS is case-sensitive in its file path interpretation, while standard HFS+ is not. The paths /tmp/foo , /tmp/Foo , and /TMP/FOO all point to the same location on an HFS+ system but to three different ones on a UFS filesystem. However, using Mac OS X Server 10.3 and higher, you can format case-sensitive HFS+ volumes, and these volumes will maintain case-sensitivity when mounted on a Mac OS X client system.

  

  Some software from the UFS world might assert case-sensitivity despite HFS+'s permissiveness. The Tab-completion feature of the bash or zsh shell command lines, for example, is case-sensitive, even if the filesystem they're working with is not.

  
  

• UFS uses slashes ( / ) as its path separator, while HFS+ uses colons ( : ). However, various Mac OS X applications accept slash-using path notation no matter the underlying filesystem format. The Finder's Go Go To Folder (Shift- -G) command lets you type a path to travel to that point on the computer's filesystem. On the other hand, the Finder's Get Info window displays the real, colon -based path of the selected Finder object if it's on an HFS+ system.

  The two filesystems have a different concept of "root ," or what the path / or : means, respectively. A UFS system's root directory is the top level of some designated disk volume, while the root to an HFS+ filesystem contains no data but has a list of available volumes. This is why absolute filenames expressed in HFS+ terms always lead in with a volume name , such as Volume : tmp:foo . (It's also philosophically similar to the filesystem root as the Finder displays it, through its Go Computer (Shift- -C) command.)

  

  Mac OS X often expects absolute paths to act as they would look on a UFS system. In the Terminal, cd / takes you to the top level of the boot volume, not to the HFS+ root . (Other volumes are accessible from /Volumes .)

  
  

• HFS+ stores two time- related pieces of metadata with each file: its creation date and its modification date. UFS stores only modification dates.

9.1.2. File Forks

HFS+ is perhaps most distinctive among filesystems concerning how it allows files to store information in multiple forks . A typical non-Carbonized application for Mac OS 9 stores its executable binary code in a data fork , and supplemental informationsuch as icons, dialogs, and soundsis stored in a resource fork . Each fork is a separate subsection of the file. Documents can also have both data and resources forks, which applications can read from and write to as they see fit.

However, Mac OS X is based on Unix, which was built to work with single-forked files, holding nothing except their own data. Modern Mac OS applications eschew all use of resource forks, instead taking one of two paths. They either store all their resources in a separate file with an .rsrc extension, kept inside the application package, or they simply store their resources as separate files inside the package. Carbon applications usually take the former, single-file route for their resources, and Cocoa applications favor the latter.

To accommodate traditional Macintosh applications and files, Mac OS X provides native support for multiple forks on HFS+ volumes, and native-like support on UFS volumes. Copying and moving such files with the Finder works as expected, whether the files reside on an HFS+ or a UFS volume.

Under the hood, however, you'll find that this task required some special engineering on Apple's part. Mac OS X stores any resource fork that happens to reside on a UFS volume as a separate file , whose original name is prefixed with ._ . For example, when a copy of the SimpleText application resides on a UFS volume, it's comprised of a data file named SimpleText , and a resource file named ._SimpleText . The Finder shows only the data file but does the work of splitting, moving, and recombining both files as they move between UFS and HFS+ volumes.

Similarly, because the Unix subsystem can't directly recognize multiple file forks residing on HFS+ volumes, the OS handles them differently. When viewed from the Unix command line, resource forks appear as separate files of the same name, but with /rsrc appended. These special files will not show up in a directory listing, but will when explicitly listed (for example, " ls Simpletext/rsrc ").

For both of these reasons, then, special care is required when handling dual-fork files from the command line. Traditional Unix file-transfer tools such as cp , mv , tar , cpio , and rsync , have not recognized resource forks and would leave them behind when moving the data fork, rendering application files useless. Mac OS X provides the CpMac , MvMac , and ditto utilities that do handle resource forks properly, and these are detailed in Chapter 2. As of Mac OS X Tiger, cp and mv also preserve resource forks, but CpMac and MvMac are included for compatibility with older scripts.

9.1.2.1. Attribute forks

HFS+ files can store metainformation in a third fork, called an attribute fork . Most commonly, this fork, if used, holds the file's application and creator codes.

As with resource forks, Mac OS X supports this fork and its codes but considers them deprecated. Modern Mac applications link files to themselves through filename extensions, not creator codes. As a user , you can also modify these application-document links as you wish, through the "Open with application" page of the Finder's Get Info window.

9.1.3. Journaling

The Disk Utility application enables journaling on HFS+ volumes. Disk journaling is a feature that both increases filesystem stability and decreases recovery time in the event filesystem directory damage occurs.

With journaling enabled, the OS keeps a record, or journal , of all write operations to the disk. If the system ever stops unexpectedly due to a crash or power failure, the OS automatically "replays" the journal upon restart, ensuring that the disk and its directory are again consistent with each other, a processes that takes only a few seconds.

Without journaling enabled, the OS must perform a check of the entire filesystem following a crash to restore consistency. This can take up to several hours, depending on the size of the disk.

Journaling does slightly decrease disk-write performance, but this should only be an issue when working with high-end multimedia, for example, when disks need to perform as fast as possible.

9.1.4. Other Supported Filesystem Formats

Mac OS X can recognize and work with several local filesystem formats beyond UFS and HFS+, as listed in Table 9-1.

Table 9-1. Mac OS X's supported filesystem formats

Filesystem type	Description
HFS+	Mac OS Extended Format. The standard filesystem format for Mac OS Versions 8.1 and later (including Mac OS X).
HFS	Mac OS Standard Format. Used by Mac OS versions prior to 8.1.
UFS	Universal File System, used by most Unix-based systems.
UDF	Universal disk format, used by DVDs.
ISO 9660	Used by CD-ROMs.
FAT	Used primarily by DOS and older versions of Windows, sometimes other media (such as some digital cameras ).
FAT32	Used by newer versions of Windows.
NFS	The Network File System (see "Chapter 10).

This list doesn't include the remote filesystems that Mac OS X can mount as network-shared volumes.