HFS File Structure Explained

By Steve Brecher, Software Supply, MacTutor Contributing Editor

Anonymous Questions

Q. I know you like to give credit to readers who send questions. But if I prefer that you not identify me, will you honor my request?

A. Yes. In particular, don't be afraid to ask "dumb" questions!

DS versus DC

Q. Loftus Becker of Hartford, CT asks how one should choose between DS and DC for data storage in assembly-language programs. Is it a question of style, or are there reasons of substance to use sometimes one, sometimes the other?

A. The MDS Assembler DS directive reserves global variable storage that the program will address with an offset from the A5 register. The linker calculates the offset of each variable declared with DS, and substitutes the offset where you use the symbolic name of the variable. The linker also puts the total size of the global area into the CODE 0 resource, so than the Segment Loader can allocate sufficient space "below A5" when the application is started. DS stands for "define storage."

The DC directive allocates static space within your code segment, at the place where the directive appears. The assembler will generate the value(s) given as arguments to DC, which stands for "define constant." DC provides a way to assemble arbitrary data instead of instructions. The assembler generates PC-relative addressing for references to DC data.

DS global storage is not initialized when the application is loaded; DC data is initialized.

DS variables may be directly written with a MOVE instruction, e.g.,

Move #1234,MyDSVar(A5)

DC storage cannot be the direct destination of a MOVE instruction, because the 68000 does not allow the PC-relative addressing mode for the destination of a MOVE. To alter DC data, its address must first be placed in a register, and then it can be written to using register indirect addressing, e.g.,

Lea MyDCData,A0
Move #1234,(A0)

DS storage is always resident while your application is running. DC data is local to the segment in which it is assembled, and goes away if the segment is purged.

DS storage does not use disk space within your application file; DC storage does take up disk space.

In sum, DS is best used for program variables, while DC is best used for constants.

SFGetFile Unmounts

Q. I'm writing a desk accessory that shows information about all online volumes. It also allows the user to change file attributes. I've noticed that sometimes when I put up an SFGetFile dialog box to allow the user to choose a file, after SFGetFile returns my DA does not show all the volumes that were there (in the VCB queue) prior to the SFGetFile. Why?

A. One of the last things SFGetFile does after the user clicks Open or Cancel is to unmount any online volume that is not in a drive. I'd guess the reason it does this is to avoid cluttering the VCB queue (list of online volumes) with disks that the user inserted and then ejected while the SFGetFile dialog box was up. A user searching for a file could possibly insert and eject a large number of disks. SFGetFile's volume purge routine does not discriminate among offline volumes which were mounted previously and those which were mounted while its dialog was active.

PRECs: Correction

In an answer last month, the format of a PREC resource was given incorrectly. A PREC resource specifies a selection of printer paper sizes. The correct format is:

n [1-word count] -- number of active paper sizes

6 pairs of words -- vertical,horizontal paper size in 120ths of an inch

6 Pascal-format strings -- names of paper sizes

The first word of the resource is a count ranging up to 6 of the number of paper sizes that are "active," i.e., meaningful. The first "count" pairs of size words and the first "count" names are "active"; the remaining pairs of size words and name fields, if any, are unused.

SystemTask within DA

Q. If some code in a Desk Accessory is time-consuming, can a call to SystemTask be placed in it? I have tried doing this with no apparent harm, but I'm concerned about re-entrancy problems.

A. SystemTask is a routine generally called in the main event loop of applications as a "courtesy" to desk accessories and device drivers that need to have their Control routines entered at periodic intervals. A DA or driver indicates such a need by setting the dNeedTime bit in the flags word in its header.

SystemTask uses a semaphore variable in low memory to enable it to ignore recursive calls to itself. Also, it will not generate a Control call to a driver that is currently executing. So calling SystemTask from within a DA or driver should be OK, and you needn't worry about re-entrancy because of it.

HFS Preview

We temporarily interrupt our Q&A format to bring you a preview of HFS, the new Hierarchical File System that is being delivered with Apple's 20MB disk. Third-party disk vendors either have already implemented or are working on HFS compatibility.

HFS -- known as TFS (Turbo File System) prior to release -- replaces MFS, the original Macintosh File System. It is, in effect, a new File Manager. Along with it comes a new Finder. However, Apple has gone to great pains to make the new system upwardly compatible with existing applications and existing disks. All MFS file system calls are supported, and HFS can handle MFS disks.

HFS implements true nested subdirectories in the file system itself. Under MFS, a pseudo-subdirectory scheme was simulated by Finder folders -- but only within Finder, and at great expense in Finder execution time. Under HFS, the Finder's desktop looks much the same, but now the folders are real subdirectories. The new Finder does have an addtional cosmetic command in the View menu, "by Small Icon," that causes files to be identified by reduced-size icons with the filename to the right of each (see Figure 1). This option permits many more files to fit within a given Finder window; it's available for MFS disks as well as HFS disks.

With HFS, it's no longer necessary to partition hard disks into pseudo-volume subsets. Instead, users can arrange their files into folders (directories) so that many files -- thousands -- can co-exist manageably on one disk volume. Directories can contain directories as well as files, making for a tree file-catalog structure. Two or more files on a disk can have the same name, as long as each is in a different directory.

HFS also uses a different scheme to allocate and keep track of used/unused space on a volume so that the minimum file allocation size can be smaller -- 0.5K, as opposed to 1K for MFS floppies or 2K-4K or more for MFS hard disks. Thus more small files can fit on a disk.

The biggest change the user will see is in the new SFGetFile and SFPutFile dialogs. Figures 2-4 show typical SFGetFile displays of the same disk whose Finder view is shown in Figure 1. In Figure 2, the user sees the folders (and files, but there are none in the example) of the volume's root directory. He opens Folder 1, and then sees the dialog box shown in Figure 3. Folder 1 in this example also has only folders within it, although it could contain files. The user opens Folder 2a, and sees the dialog shown in Figure 4 which displays the four files and one folder that are the contents of Folder 2a. The user still hasn't located his file, and he wants to go back up the directory tree. He clicks on "Folder 2a" on top of the scroll box, and gets a pull down menu of all the directories he has traversed back through and including the root (which has the same name as the volume). By dragging the mouse down and releasing, just as for a normal menu, the user can go back to any of the higher-level directories -- he isn't limited to going back one level at a time.

The SFPutFile dialog box (not shown) has a new scroll box, like SFGetFile's, in addition to the TextEdit item for entering a file name. It works like SFGetFile's, but it shows only folders (directories), not files, since its only purpose is to enable navigation among directories before specifying the name of a new file to be created.

Now let's turn to the programmer's view of HFS.

Each element of the file system catalog tree -- each directory or file -- is called a Catalog node (Cnode). The directory at the base of the tree is called the root, and has the same name as the volume. Intermediate nodes in the tree are always directories; terminal (leaf) nodes -- those with no branches extending from them -- are either empty directories or files.

Each Cnode has a name (such as "MacPaint Documents Folder" or "Letter to Birks, Druffey, & Co."). Cnode names are strung together, with colons in between, to form a pathname. Each element of a pathname except the last must be a directory; the last may be either a directory or a file. A full pathname starts with the root directory name, and describes an arbitrary path to a given Cnode; for example:

My HFS Disk:Folder 1:Folder 2a:Sources:Foo

A partial pathname is one that either starts with a colon or that consists entirely of a single name, e.g,

:Folder 2a:Sources:Foo
Foo

An empty pathname element -- a pair of colons -- signifies a move up the tree, i.e., it stands for the parent of the current location. Example:

My HFS Disk:Folder 1:Folder 2b::Folder 2a:Sources

Three colons signifies a move up two levels, four colons up three levels, etc.

Internally, each directory CNode has an identifying number -- a DirID. Cnodes can be identified to HFS system routines by using a partial pathname, together with a DirID that denotes a directory from which the partial pathname specifies a path to the desired Cnode. Note that full pathnames may in some cases exceed 255 characters in length and thus might not be respresentable as Pascal-format strings.

By using the new file system call OpenWD, the programmer can specify a working directory. The call returns a WDRefNum which can be used in subsequent calls to identify a Cnode. WDRefNums are negative, like VRefNums, but their values won't overlap those of VRefNums. When a WDRefNum is passed to a file system routine in place of a VRefNum, the system will look up the volume and the directory from the associated Working Directory Control Block (WDCB) that was filled in by an OpenWD call. The system creates a fixed pool of WDCBs at startup, and maintains its contents; the programmer need not be concerned with WDCBs directly.

The working directory scheme is one of the keys to compatibility with MFS. Under HFS, SFGetFile might return a WDRefNum in its reply record in the field in which it returns a VRefNum under MFS. If the program then passes that value to an _Open call, the desired file will be opened; the program needn't be conerned about nor know whether SFGetFile returned a WDRefNum or a VRefNum.

Existing programs that pass volumename:filename strings to the File Manager rather than using VRefNums will not be able to access HFS files (except those that are in the root directory). This includes programs written in C which use stdio routines, since those routines take only a string as a file identifier. (Specifically, it includes the programs in the MDS package.) Such programs can be fixed by inserting a call to SetVol between the call to SFGetFile and the call to fopen(). If SetVol is passed a WDRefNum, it will set the default directory as well as volume. If permanently changing the default volume/directory is not desireable, the previous default can be obtained first via GetVol, and restored after the fopen() with another SetVol. C stdio programs written in this way will work under both MFS and HFS.

Memory structures such as the Volume Control Block (VCB) and File Control Block (FCB) have expanded. However, all the new information is in the expansion, so that programs which access these structures under MFS will still find the old fields in the same place. Existing programs that access the FCB buffer -- which is an array rather than a linked list -- won't work, however (Apple has been warning developers of this for some time).

As mentioned, the existing MFS File Manager calls are all supported under HFS. In addition, there are some new File Manager routines. Some of the new routines are extensions of the old ones which return additional information -- HFS-specific fields -- in expanded I/O parameter blocks. Other new routines are similar to their MFS counterparts except they accept an additional DirID field in the parameter block. The rest of the new routines have no MFS counterparts; e.g., a routine to move a file or directory from one directory to another on the same disk (does not physically move the file, only changes the catalog); and the routines which open, close, and interrogate the contents of WDCBs. The File Manager changes will be documented in a new chapter of Inside Macintosh to be available soon (if not already available by the time you read this).

The initial release of HFS is RAM-resident in high memory. The final release is expected to reside in the new ROM (Rumored-Only Memory). HFS takes up additional system heap space (e.g., for the WDCB pool and an enlarged trap dispatch table); and the initial RAM version uses even more system heap space for system patches. The system heap is larger, but even so it's relatively cramped; system heap hogs beware.