Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve » Developers Workshop

Outlaw the Unix™!

If it's to come to this, then so be it.

Get It

Try It

CUPERTINO (Rixstep) — This is not only the season of good will. It's also the season of deprecation. Some deprecations are more ominous than others.

Apple have officially announced the deprecation of performFileOperation:source:destination:files:tag: from NSWorkspace.

https://developer.apple.com/documentation/appkit/nsworkspace/1524886-performfileoperation?language=objc

There is no replacement and there is no workaround. Apple's suggestion? Go fishing in NSFileManager. That's lame.

Most often, when the deprecation epidemic hits Cupertino, there's a workaround available, and, at least in the long run, some good sense to it all. But not here, not this time.

This deprecation is just downright dumb.

Apple & File Systems

It doesn't take a postgrad degree in comp sci or even advanced skills in Google to see Apple are a mess when it comes to file systems. Their initial MFS had to be scrapped in silent mode because it was so ridiculous, only to be replaced by HFS, which used a weird tree model where one of the branches is never used.

HFS also has the not-so-coveted distinction of being just about the only file system in existence that is incompatible with Ken Thompson's 'hard links'. Even the ridiculous 'FAT' file systems from Redmond were theoretically compatible! But not Apple.

Instead they taxed a poor sod with providing a workaround that offered a 'modicum' of compatibility. And what a mess it's been. Short version: hard links, so valuable on Unix systems, have never worked as designed on the systems spewing out of Cupertino. Never.

Apple kept hiding the ugly mess in directories at root with stranger and stranger names. Those brave enough to dig down beneath the ordinary API level could see what was going on, and so Apple kept running and hiding again and again. How childish for a major international company.

Not to speak of the countless well-publicised data disasters their thinking has caused over the years. And then, as if to add insult to injury, some nondescript nobody from One Infinite would defiantly proclaim:

'Works as designed!'

Not to speak of the weird way file management in general is dealt with at Apple - yet another thing that's famously 'unique' at Apple. The macOS command line doesn't work that way, no other operating system anywhere works that way. Only Apple. The danger of obliterating huge hives of files is always imminent.

And what is Apple's official response? You guessed it.

'Works as designed!'

Ordinary files are allowed to obliterate entire file systems. The very first ever release of Safari did just that. Directories can replace symlinks. Symlinks can replace anything. And so forth and so on.

File management code at the most basic level requires a level of meticulousness tantamount to that required of driver writers. Apple's 'method' is easy: it studiously steers clear of all those high-brow details - and with expected results, as the world has seen over and over again.

Those who've been around long enough to have the headaches to remember: they can still see, before them, the red ink in Apple's developer notes for Carbon, cautioning them to not use certain functions as their use might hose the whole fucking file system. Encapsulation isn't a word bandied about much in Cupertino.

[No self-respecting industrial strength file system would ever allow what Apple's has done over and over again. Shame on the dweebs. Ed.]

And the stories came out. How the Nexties were resented. How no one really liked Unix anyway. How things were so much better back when there was only one folder to put everything in, all software was written in Pascal, and with only one acceptable colour.

David Pogue came out with his books, giving Chris Stone two chapters each time to belabour the bleating obvious that 'OS X is not MacOS'.

Then Apple finally took the 'Mac' out of the OS name, and luminaries like Sasser and Gruber (no, not the reindeers) scratched their heads and wondered why. And when Apple, under Tim's eagle-eye leadership, once again renamed the monstrosity, this time to 'macOS', the crowd went wild.

Almost as wild, or so it's been reported, as when they booed Steven Paul Jobs for showing them the NeXTSTEP File Viewer.

The NeXTSTEP File Viewer wasn't that much different from today's ~~Loser~~ Finder in macOS. Except it was of course way superior. But the fanboys dirtied their knickers and made it clear that Steve was a very very bad boy.

And so Steve went back to the drawing boards. Arno got to head a team. And Arno's team began to rip the fucking guts out of NeXTSTEP.

It's in AppKit, you silly fools

Take a look at the following screenshot from NeXTSTEP.

NeXTSTEP Workspace Manager

Admittedly it's brilliant. The copyright goes to 1996, but the actual product is much earlier.

The artwork - the graphics - is of course by Keith Ohlfs, who was hired on by Susan Kare, who came back to Steve in Redwood City after making all the Windows icons for Bill, after she'd done the original icons for Steve's Macintosh.

The software itself is written by Lee Boynton. And by Jean-Marie Hullot, the dude what came to Steve with something he called 'SOS Interface', which so blew Steve away that he rushed into town to buy up all available copies, and then hire on Hullot to write Interface Builder for NeXT. And then there's Bertrand Serlet, later a head of software production at Apple.

Anything else curious about that screenshot?

Yes. It's visible. Why?

NSWorkspace goes through NSFileManager to get at the nitty-gritty. NSFileManager isn't visible. That's why it's in the Foundation framework.

Traditionally, NeXTSTEP had two major frameworks.

AppKit
Foundation

Foundation is for all the 'abstract' stuff - things you never see onscreen. Check, for example, where NSString is located. Or NSArray. Any coins dropping down?

But NSTextView - where's that?

https://developer.apple.com/documentation/appkit/nstextview?language=objc

'The NSTextView class is the front-end class to the AppKit text system.'

Note the crucial words 'front-end'...

Now check up on NSWorkspace.

https://developer.apple.com/documentation/appkit/nsworkspace?language=objc

'A workspace that can launch other apps and perform a variety of file-handling services.'

No mention of 'front-end' there. What gives?

Ask the people at GNUstep.

GNUstep

GNUstep started when a developer was tasked with porting his software from NeXTSTEP to a new platform. Instead of rewriting the danged thing in another (far inferior) language, he instead set about duplicating the AppKit and Foundation frameworks.

A casual conversation with the owner of the 'workspace' code at GNUstep, plus a quick review of the code, revealed all. The utter shock and horror expressed, when told what Apple were up to, could not be misinterpreted.

'Oh no! We would never do that!'

For their code goes through redundant and lugubrious pains to make sure nothing untoward happens to the user's system - precisely as NeXTSTEP had done before them.

And Apple? They get ready to grind their organ and once again sing their monotonous mantra 'works as designed'.

NSWorkspace is in AppKit for a reason. NeXT placed it there because it was visible. Then Apple made it disappear.

performFileOperation:source:destination:files:tag: is not the same thing as a fully encapsulated (and protected) file system object, but it's as close as it gets on macOS.

Apple are not going to offer replacements for what goes missing when NSWorkspace is sent to Siberia™. They're being vague about this just like when they got rid of the messaging framework.

Oh yeah, sure, the technology is still in the system, just as it is for messaging. Duplicating file system items, etc. It's just that they're not going to let ISVs get at it anymore.

What fun. And all for this piece of shit?

They say that several methods in NSWorkspace have never been implemented, so who cares?
But the truth is they already have the code - but they transferred it to 'funny face' above, not to where it belongs.
They say that one can use NSFileManager instead.
And indeed, NSWorkspace has been a sort of 'wrapper' for NSFileManager. But NSWorkspace has more - more that's going to stay only in 'funny face'.

An operating system without a fully encapsulated file system that is capable of protecting itself cannot be considered 'prime time'. Apple's speckled history since the 'merger' with NeXT is sad reading. No other 'open source' platform has been plagued with embarrassing and totally unnecessary scandals like Apple's.

Then again, Apple today is the world's most powerful private company. So everything's going to be alright.

Who?

'Engineering has determined that this issue behaves as intended based on the following information: When the Save panel asks if you want to replace a file or folder of the same name, and the Replace button is clicked, expected behavior is received.'

'Apple has no sanity checking to protect you: no matter what you ask Apple to do, they'll try to do it - even if it means hosing your entire system.'

'It's easy to see where this leads. Directories can be overwritten by files; directories can be moved over subdirectories and subdirectories over their parent directories - and Apple's file system API won't even burp. But your computer will: you'll hose it.'

'Five minutes of hacking is all it takes to create a simple Cocoa application that irrevocably destroys an entire macOS file system.'

Postscript: Send in the Clowns

Steven Paul Jobs once famously said that his NeXTSTEP was 'five years ahead of its time'. Our estimate here was that it was twenty-five years ahead of its time. Steve's statement is from the early 1990s. It's now gone twenty-five years, and the year is 2017, soon to be 2018.

No matter that Apple no longer have a dedicated group for OS development, that OS - and its file system - must be taken seriously.

Things aren't being taken seriously when a super-major corporation can release three iterations of a revolutionary smartphone device with every client application running as root. And it doesn't help (or does it) when their Chief Fanboy proclaims 'don't think for a second that they didn't think about that long and hard'.

[And of course they finally woke up with .3. Oops. Ed.]

A file system must be completely open as regards APIs, yet still hermetically sealed. From the moment a client application requests an operation from the file system, the file system must take over - completely.

The file system must be prepared to handle 'OOB' situations and perform all possible (and impossible) sanity checks. Under no circumstances must file system data be jeopardised. Apple cannot allow or encourage or force ISVs to resort to situations where the infamous red ink has to flash out amateurish warning signs.

And there's never been an excuse for migrating vital NSWorkspace code into ~~Loser~~ Finder and never letting it back out again.