The Macintosh File System Manager (FSM) is an abstraction layer that sits below the Macintosh File Manager, but above the low-level operating system and device drivers. The purpose of the FSM is to allow foreign file system components to be written and deployed on MacOS 8.x and 9.x so that storage devices formatted with file systems which Macintosh does not understand can be utilized with MacOS. The FSM can best be quickly described by means of a simple example, which follows.
When a MacOS Classic application makes a call to the Macintosh File Manager, the FSM first intercepts this call to determine whether the call is being made to a native MacOS formatted device (such as HFS, or HFS+). If it is, then the call is passed directly to the File Manager which services the request. For example, if Adobe Photoshop calls FSRead to read data from a file, the FSM looks to see if the read is being performed on a file which resides on an HFS or HFS+ volume. If it does, then the call falls through to the native Macintosh File Manager, and the data is read. If however, the FSM determines that the file in question resides on a device whose file system the MacOS does not recognize, then the FSM looks in a table stored in memory for an FSM plugin whose file system signature matches that of the device the file resides on. If a matching foreign file system (FSM) plugin is found, the FSRead equivalent call in the plugin is called. If no matching foreign file system is found, then an error is returned. However, this is highly unlikely because without the foreign file system plugin installed, there is little chance that the volume would have been mounted, which of course would have prevented the user from ever opening the file to begin with.
Each foreign file system plugin in Mac OS 9 is compiled into a resource in a System Extension. This System Extension contains the usual INIT resource which performs the job of loading the foreign file systems the Extension contains at startup time. If the FSM is present at system startup, and if the user has installed the System Extension in his or her Extensions folder, then the foreign file system(s) contained in that System Extension will be loaded. When loading occurs, several things must happen, most of which are usually performed by the Extension at system startup:
The INIT code searches the Extension file for valid foreign file system (FSM) plugins. Any valid plugins found are loaded into the System Heap and remain resident.
The INIT code then reads each foreign file system plugin's four-character signature code and installs that signature along with a pointer to each file system into the system's FSM lookup table.
Once loaded, the FSM assigns each foreign file system a file system descriptor for reference.
FSM Plugin Internals
So how is a foreign file system plugin implemented internally? Since each application that calls the File Manager may actually be indirectly passing calls through to an FSM plugin, each file system plugin must essentially implement a 1-to-1 mapping of routines in the File Manager. Some routines are required; some are optional and can be omitted based on the level of functionality desired. For example, in the File Manager, there are standard calls for opening, closing, reading, and writing files. There are many variants of each of these calls. Therefore calls such as FSOpen, FspOpenDF, Hopen, FSClose, FSRead, FSWrite, PbxRead, PbxWrite, MountVol, and UnmountVol as well as others must be implemented in the FSM plugin.
Each FSM plugin implementation will have its own version of these calls (as well as others). For calls in the plugin whose functionally is identical to that of the same call in the File Manager, that routine in the FSM plugin simply passes the request onto the File Manager version of that call and returns the error code returned by that call. From this one can see that most FSM plugins will implement only a subset of the File Manager calls. However, that subset can still be large as there are upwards of 70 calls in the native MacOS File Manager. Other Managers which are not part of the File Manager per se should also be implemented, but are not required for basic file I/O functionality to work. Examples are the Desktop Manager for icon support, and various Finder Interface routines. The level of support for these routines is determined by the extent of the functionality desired. The more complete the support, the more the file system will behave on the desktop in a manner that users expect. The Toolbox Assistant excerpt at the end of this document summarizes the routines in the important MacOS Managers which need to be implemented by each plugin.
Comm Proc and HFSCI Proc
Each FSM plugin must implement a Communications Proc (Comm Proc) and an HFS Component Interface Procedure (HFSCI Proc). Both are normally stored as code resources in the System Extension. The Comm Proc is the main communications channel that the Mac OS uses to send messages to the FSM plugin. The HFSCI proc is the entry point where the plugin receives the File Manager-like requests for specific file access calls (i.e.: the equivalent calls that implement the File Manager's equivalent calls for the foreign file system - such as PBRead, PBWrite, etc.). Both the Comm Proc and the HFSCI Proc must be implemented according to very strict guidelines.
Bringing Foreign File Systems Online
Another critical consideration in developing FSM plugins is interfacing the File System with the Macintosh Finder desktop interface. Since users manipulate volumes and their contents from the Finder, each volume that is controlled by a foreign file system must provide the expected behavior. Every FSM plugin must provide at least the following services when bringing a volume online:
• Read each volume's file system and ID and locate a matching foreign file system in memory which can support it.
• For each volume, allocate a Volume Control Block (VCB) in the system heap and fill in that VCB's fields.
• Allocate a Drive Queue Element (DriveQEl) in the system heap.
• Call AddDrive using the newly allocated DriveQEl in order for the volume to be linked into the MacOS.
• Add the VCB to the VCB Queue Header.
• Call PostEvent to post a disk inserted event which will trigger the Finder to call MountVol which will mount the volume on the desktop and bring the volume online.
When a volume controlled by an FSM plugin is unmounted, the reverse of this process must happen and the FSM plugin must clean up any memory it allocated.
The Disk Initialization Package
When writing FSM plugins, the fact that the user may select a volume in the Finder, then choose "Erase Disk" from the Special menu must be considered. Since the MacOS does not know anything about the foreign file system, the FSM plugin must also implement code that the Disk Initialization Package can use to format the volume. This may or may not involve finding the device's driver from the Name Registry and then sending commands to the device driver or to its appropriate manager (ATA, SCSI, USB, Firewire, etc) to write the new volume format out to the device. If the media type is read-only, then the Disk Initialization Package component of the FSM plugin can be omitted. Disk Initialization Package code is stored in the System Extension's file in the same manner as the HFSCI Proc and the Comm Proc.
Summary of calls needed to be implemented by an FSM plugin for Mac OS 9:
(Sorry, i haven't added the Toolbox Assistant excerpt yet).
