|Home » Learning Curve » 4350557
When unacceptable behaviour is accepted.
As David Pogue and Chris Stone have repeatedly pointed out, OS X is not a 'MacOS' - it's Unix, or at least it's supposed to be. And yet the 'POSIX' compliance Apple are so eager to maintain is simply not there.
Apple's struggle with POSIX compliance is an ongoing story that will not end until Apple come around and finally junk their HFS+ file system.
When work began on porting NeXTSTEP to Apple, concessions were made. A decision was made to use the legacy Apple file system known as HFS+. This file system is incompatible with Unix.
It became the task of the NeXT and Apple engineers to force fit HFS+ onto the Unix standard - a task doomed to failure.
Why the Twain Can't Meet
Apple's HFS+ is unique in the world of file systems in that it cannot be adapted to Unix POSIX standards. Most other file systems do not directly support POSIX but can be adapted in a pinch. HFS+ cannot.
A POSIX file system has to allow for so-called hard links: POSIX hard links may be placed on files (but not directories) and exist as ordinary independent files in the file system.
A hard link to a file is indistinguishable from the original directory entry; any changes to a file are effective independent of the name used to reference the file.
HFS+ on the other hand likes to trace back from file records to file names; when the supported POSIX standard admits of multiple names for the same physical file, this exercise becomes futile.
They're Already On Your Disk
Your OS X system already has hundreds of these hard links. Obviously if something were to happen to them, your operating system would cease functioning correctly.
Click here to see a list of hard links typically found on 'out of the box' OS X.
All told, there are well over one thousand such files, and they're all important, and in many cases it's immediately obvious why they're so important.
But HFS+ can't touch them; if it does, they're destroyed - your computer becomes dysfunctional.
Why Do This?
Why would Apple do this? Why would they leave your computer incomplete? If it was known - and surely it must have been known - that the POSIX implementation was incorrect, why leave it like that?
'Resource forks'. Most earlier Apple software was dependent on resource forks; Apple wanted these applications to have a chance to also run on OS X. They needed to provide the 'Carbon' interface and they couldn't change the file system. But the file system is not POSIX.
So how try to simulate hard links? An incredibly egregious process which removes the file record to another area of the disk from which it can never return.
So hard links can exist - but can't be used according to POSIX standards. The idea with hard links is that the physical files will still be edited from time to time; trying to do this with OS X will result in disaster.
This disaster is more or less limited to the OS X 'shell' consisting of the NeXTSTEP 'document controller' class. It is this class which governs the file I/O of all OS X 'Cocoa' applications.
But the idea with OS X is that all software will be Cocoa - yet when running HFS+, the governing class botches the job.
How Long Will This Go On?
NeXTSTEP engineers, initially happy to see the platform emerge into the mainstream, were willing to accept compromises such as this in the hope they'd gradually be phased out.
Apple's most recent release, 10.4 Tiger, actually moves in the opposite direction, corrupting open source Unix code and sticking with HFS+. And Apple's official position on the hard link issue is that it's 'expected behaviour' [sic].
Expected yes - given the scenario outlined above - but acceptable? No.
They're Already On Your Disk
HFS+ - Taking a walk in the orchard
3662262 - Back to HFS
Fork-U-2 - It's not an outrage - is it?
NCE - The OS X No Code Editor 1
NCE - The OS X No Code Editor 2
volfs - Square pegs in round holes
A Path to Unix
Is It Unix?
A Weird Bug