Red Hat Diaries/0069

You eff ess? Don't!

OS X comes with the option to install with either the standard HFS+ (HFS Extended) or UFS, a file system used in more vanilla versions of Unix. There is no explanation of what this entails. I personally was very tempted to try UFS on my last clean install of Jaguar the other week. Now that I know more about what's going on, I'm glad I didn't. Before you go and make a leap you might regret, read this so you know too.

To better explain what will happen if you use UFS for your Mac, it is easier to explain what happens if you don't - that is, what you get with the standard Mac file system.

Way back in the beginning of time, Mac designers saw things in a very document-oriented way, right down to the disk sectors themselves, and to this date there is no other file system which has gone so far - or so deeply - to implement these ideas.

Think in terms of Windows: when using any part of the shell such as Explorer, you get up all sorts of pretty icons for all your various file extensions. The Windows Registry has a key, HKEY_CLASSES_ROOT, primarily used for storing all that horrid CLSID stuff, but also for connecting file extensions with file types, icons, and default applications.

So given an extension such as 'txt', you can find a display icon. This icon may be denoted already with the extension, or it may be denoted with the file type ('txtfile') the extension is associated with. Either way, your possibilities are limited - you can either have icons (and other associations) on a per-extension or a per-file type basis, but no more.

Mac designers may have considered this option, but if they did, they discarded it. And whereas all this stuff is in a separate location on most operating systems, it's burned into the actual directory entries on the Mac.

File systems handle their on-disk organisation in different ways. NTFS has master records of two disk sectors for each file (or directory) with security descriptors, long and short name variations, and the extents - i.e. where the rest of the file can be found on the physical medium. MS-DOS, one of the most frugal of the lot, has the file name, a number of bitwise attributes, the start sector, the time stamps, and the file size. Unix has its inodes - in other words, directory entries have only a file name and an index into a master table of file system information.

But that's about it. None of these major file systems have any information about document associations at the disk sector level - except the Mac.

In addition to all of the above, the Mac stores a creator code and a file type. The creator code denotes which application created the file; the file type categorises it. The creator code provides the default association; the file type gives a clue as to what other applications might be able to deal with the file.

And the icon for the file may be hiding in the file itself. Individual files can have their own individual icons. This is possible because each file on disk has two so-called 'forks'. (Think in terms of Cutler's NTFS streams and you'll get the picture.) File data is stored in the data fork, and resources (such as icons) can be stored in the resource fork.

Normal file management tools won't understand this, but a Mac will.

The Icon Factory has an impressive collection of Mac icons; downloading these files to a Wintel machine will be meaningless. They're empty files - all they have is an icon resource in their resource fork. The official size of these files is zero.

It gets better. It is possible to copy an icon file of this type onto another file - or directory - without destroying the data in the target, because the source file has no data fork. Thus it is possible to customise files in a way that is inconceivable on any other platform. Any Icon Factory icon can be dropped onto any Mac file system object without damaging it - all that is changed is the object's appearance in the Finder. Only the resource fork is overwritten.

Which is admittedly pretty nifty. The trouble is that no other file system is capable of understanding things on this level.

Resource forks don't have to be used for icons. They can be used for almost anything. The structure of file I/O with the resource fork makes it ideal for small flat database files - just as one example. And given the long-standing nature of this file system in the world of the Mac, it is not surprising that a great number of vendors have found inventive ways to exploit the resource fork.

Or what about documents with their own individualised default settings? What about a file called 'file1.txt' which comes up in the upper left hand corner of your desktop, with tons of application features turned on, but another file called 'file2.txt' which comes up in the lower right hand corner of the desktop, with all of the features turned off?

This is inconceivable on any platform but the Mac, but on the Mac it's as easy as pie: all you do is make your application sensitive to configuration settings stored in the document's resource fork.

Until recently the reigning OS for the Mac was MacOS 9.2, a 16-bit system with far too few capabilities. The jump to OS X meant a lot of work for independent software vendors. Apple made things a bit easier by exposing their so-called Carbon API, a layer between OS X and the computer hardware. It was possible for these vendors to effect a half-hearted update of their products to Carbon without going the full gauntlet to Cocoa - which is exactly what most vendors did. Microsoft's products for the Mac, such as Internet Explorer and MS Office, to cite two well-known examples, are not Cocoa software; they're 'carbonised'. Engineers subject their legacy code to a relatively minimal rewrite and suddenly everything runs natively on the new operating system.

Or does it? A lot of the 'carbonised' apps out there carry legacy assumptions about the existence of resource forks and similar on-disk data the Mac has always had. These applications will not run on any file system but Apple's own HFS+.

There is evidently a bit of a war going on in Cupertino. On the one side the die-hard Mac engineers want to preserve as much of this rather brilliant document orientation; on the other side the NextStep engineers would rather see their operating system implemented fully.

The NextStep camp has no replacement for the cool stuff the Mac camp has. The NextStep camp wants everything based on file extensions. OS X will today consider both sides of the feud when deciding what to do with your files. The unofficial word is that developers should still apply for creator codes, but that these might not be in use much longer.

Either way, as long as legacy applications are around that have not made the step up to Cocoa, odds are that something will break if you don't use HFS+. And stepping up to Cocoa is no guarantee that an application will run on any other file system anyway: the resource fork is still there, and although Project Builder recommends not using it anymore, it's certainly not about to prohibit its use.

In many ways, the Apple wouldn't be an Apple without it.

Click here »