Sanity Checks at Apple

OS X user folders are getting hosed - again.

Get It Try It

Build 48 of Safari rolled out only minutes after Steve Jobs announced it at Macworld. Eager surfers were poised to get the URL. And within minutes their systems were dysfunctional and when they restarted their systems all their files were gone.

They couldn't even log back in.

Apple scrambled to get the fix uploaded and made the indiscreet boner of giving it the same build number and not saying a word. Apple users at the Apple discussion forums quickly figured out what was going on and ran message digests on the downloads. They of course discovered there were two different build 48 Safaris.

The first build 48, released as soon as Steve Jobs made the announcement, hosed people's drives. The second build, released a few hours later, was innocent. The message digests proved this.

What had Apple done wrong?

Superficially there was a programming error in Safari. Safari used the wrong default directory for downloads. But that's not really where the fault lies. For even if Safari had been set to start in the wrong directory, it should never have been allowed to overwrite a directory - the user's home directory and all within it - with a file.

And any sensible self-protecting self-respecting file system wouldn't let users - or software such as Safari - overwrite directories with files or vice versa. Yet Apple's OS X did.

And still does to this day.

Earlier in the week Rob Griffiths' Mac OS X Hints published an article entitled 'Be aware of possible data loss with TextEdit's Save dialog'. The author made it clear this was not an issue solely for TextEdit but others typically tried to dismiss it anyway, one going even so far as to claim he'd studied the source code to TextEdit and the application was 'working as designed'.

No file system that overwrites folders with files or vice versa is working as designed.

Other claims were made that the issue even extended to iWeb, and again, voices were heard claiming this is 'as designed'. And again it was not.

Test it Yourself

It's very easy to see how a real file system works: you can set up a test yourself.

In two directories create the items 'foo' and 'bar'. In the one directory let 'foo' be a file and in the other a folder. Vice versa for 'bar'.

Now fire up Finder and open windows on your two directories. Drag first 'foo' from the one window to the other. Then 'bar'. In both cases you'll overwrite an item with something that isn't its type. Very bad.

Now compare this with the command line. Set up your 'foo' and 'bar' again in both directories and try the 'cp' and 'mv' commands on them. You won't get far.

% cp foo dir2
cp: cannot overwrite directory foo with non-directory foo
% mv bar dir2
mv: bar: Not a directory

Why They Do It

Given that there are safety checks in Unix, the question becomes 'why do they do it'. And the answer is twofold.

Firstly, the file system does not want you the user to screw up and lose all your files by accident. Secondly, the file system wants to protect itself. It cannot and will not allow 'insane' file operations.

Sanity Checks

Sensitive code - especially file system code - is riddled with what the profession call 'sanity checks'. These are lugubrious snippets that just make sure some sort of wacky parameters haven't come in. Such as copying a file system hierarchy onto itself. Or overwriting a file with a directory. Or a directory with a file.

NeXTSTEP used to have code like this in their workspace and file manager. GNUstep have it today. In fact GNUstep have several different (redundant) levels of sanity check code just to make sure nothing untoward is being suggested and going to happen.

But somewhere along the line in the momentous migration from Redwood City to Cupertino this code got dropped out. Leaving OS X users today sitting ducks - not only for the enterprising black hat but for their own otherwise innocent mishaps.

Xfile System

Users of the ACP's Xfile System will receive an update later today that fully protects them against this flaw in OS X.

See Also
Learning Curve: A Sanity Check for Apple