Apple's NSDocumentController Taking Liberties

Apple did it again.

Get It Try It

This is a disgrace.

There are always some things you don't detect immediately - even if it's about Apple and you're otherwise on full alert, prepared for the worst.

This relates to that whiskered issue with NSDocumentController, the way Apple bastardised that excellent NeXT code way back in the day, perhaps ten years ago now. There has never been any - much less any adequate - explanation for this cosmic blooper, and, for years, Apple issued directly misleading diagnostics when unwitting users tripped over their utter nonsense.

When you're saving a file, you're supposed to write to it. This is common sense, so common, so sensible, so fucking obvious that it seems redundant to even mention it.

But not in the topsy-turvy world of Apple. Apple: a company down on their bare knees and saved by the technology of NeXT Computer of Redwood City. They never understood what they had. (They never appreciated it either. They couldn't even program in C in those days. For real.)

So some congenital idiot noticed he couldn't save files he'd previous marked as 'read-only' and most likely had a shit-fit. Oh noes! We have to stop that!!1! And so the 'engineers' (loose term) came up with a doozy.

For NSDocumentController - per the code emanating from Redwood City, acknowledged as brilliant code in a brilliant system - had many purposes.

The first purpose was to avoid rewriting code over and over again. This was something the moronic adepts of Pascal in Cupertino had no clue about. They were totally OK with writing and rewriting and rewriting hundreds of lines of code for each and every one of their pathetic beige box mishaps. (No, they weren't very gifted - you heard otherwise?)

But that's what NSDocumentController did - it synthesised hundreds of lines of weary identical code into - nothing. You didn't even have to know the name or path to your file anymore - you didn't even come into contact with it in NeXT/Cocoa. You just wrote your app and it just worked.

Brilliant, isn't it? The diehards in Cupertino, overwhelmed by a vastly superior technology, seethed.

The second purpose was to provide for failsafes against blackouts, brownouts, and other assorted exceptions - something Apple's back-asswards code never could dream of. (Apple are notorious epic fails when it comes to basic computer functionality such as filesystems - and you trust them?)

File buffers could be intermittently saved to a neutral third location during an editing session. This enhanced the security and stability of the system immensely. And, when the user finally wanted to save the file, NSDocumentController dutifully copied from the third location to the actual destination, checked that the copy was successful and integral, and then removed the temporary file.

And it worked brilliantly - until some typical excuse for homo sapiens at Apple ran into a snag and couldn't save a file he himself had marked 'read-only' (but was too stupid to remember).

So - the solution? The solution to placate that Apple suit who was beside himself with frustration? Simple.

Change NSDocumentController's final 'copy' operation to a 'move'.

A file move obliterates your original file. (Thanks Apple!) You can no longer write to it - it's gone. Now NSDocumentController will simply do a bit of switcheroo with directory entries, standard move essentials, and, suddenly, you can do - anything! You can write to files that are write-protected! Isn't that grand?

Oh it's grand alright - it makes any filesystem aficionado reach for the flight bag. It's so fucking stupid that it defies description. And guess what? It doesn't always work. That's right: sometimes this stupid scheme blows right back in Apple's pathetic face.

For what happens when the parent directory's mode does not include write permissions?

Moving a file involves changing the contents of two directories, the source directory and the destination directory. If either of those directories do not have write permissions, the move cannot work.

Oops! And what was the brilliant move by Apple for that eventuality?

They had none.

They simply issued a diagnostic that something was wrong with a file, not a directory, leaving the user dumfounded. The solution was not, as Apple insisted for years on end, that the user check the permissions on a file. The solution was to do something about the permissions on the file's parent directory.

But, over at Apple, they just sucked their thumbs and hoped that not too many people noticed.

We noticed.

Some ten years later - read it again: ten years - they finally changed the diagnostic. The wording is still something less than helpful, but it is a bit different for when it's a directory creating issues for Apple's finest.



And then to today.

We've all had to live with this idiocy - and innumerable other Apple idiocies - all these years, and who knows why, but today's takes things to another level.

Apple's NSDocumentController Taking Liberties

For it turns out that the perverse 'geniuses' behind this accommodation for Apple resident stupidity go even further to preserve their 'illusion'.

They actually go into the 'file flags' field.

File flags, asks the typical Maccie window licker?

Yes, file flags. The most powerful variant on access control in Apple's quiver. They of course override ordinary file permissions, but they even override access control entries, even though Apple will never provide documentation to that effect (they probably don't even realise this themselves and wouldn't know how to check).

The low word file flags are the user flags and can be reset by the user.

The high word flags normally require a reset in single user mode, even if they don't require privilege escalation. In this case, it's the 'No Unlink' (0010) user flag that's involved.

The 'No Unlink' flag is set by the conscientious user to make sure a file is not removed by accident - it's a failsafe often implemented by Unix users to increase filesystem security.



The 'No Unlink' flag is automatically cleared by Apple's cockamamie version of NSDocumentController without a sound. There is no warning issued. The flag is not restored either. The only indication you'll get is if your file is marked with the lowly 'read-only' (0400). Apple's bastardisation of NSDocumentController will clear the file flag as a matter of routine - of Apple routine.

This 'anomaly' was discovered by accident - by happenstance. (Auric Goldfinger has things to say about happenstance, surely you remember how that ends.)

The question is: what else will we discover about Apple's undocumented, Apple's completely hidden, small hacks and attacks on the integrity and legacy of Unix?

You won't find sophomoronic things like this over at IBM, or Red Hat, or OpenBSD. Perish the thought. You find them only at Apple, where they continue to stomp their gift horse around. It's disgraceful.

Isn't it time that you too considered a better, a safer, a more mature and friendlier Unix platform for your future needs?

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.