About | Buy the Software | Forum | Industry Watch | Learning Curve | Newsletters | Products
Home » Learning Curve » Red Hat Diaries

20070610,00 — MDItemMarkAsUsedWithPathAndCatInfo


Get It

Try It

The day Linux gives the Mac diagnostic that you can't open a file because you don't have the application is the day Linux becomes non-Unix.
 - Doug McIlroy
Metadata sucks balls.
 - Steve Gehrman

I'm offline and I'm furious. Let's go back two years (or more). But before we do let's explain for those who don't know who Doug McIlroy is. You can find it at Wiki or Google but Doug today is back at Dartmouth. Doug was the 'father' of Unix - he's the dude what told 'dmr' and 'ken' how to do it. His rules for good programming are the rules that permeate our world of computing today. Thank you, Doug.

But back two years (or more). Rene writes a letter. He was using the 'open file with application' sheet in Xfile. [The same sheet is available in Xscan, Xfind, Xshelf, Tracker, Undercover - everywhere: it's a framework thing.]

What happened to Rene was that right when he was going to hit Enter he accidentally flubbed and hit another key - and one extra character got put into the 'file' field. And what happened was Xfile crashed.

We tried it and nothing happened - and nothing should. Rene was on Panther; we were on Jaguar (which in terms of quality of code is still the best).

Xfile runs the sheet through the framework and the framework calls the ubiquitous -[NSWorkspace openFile:withApplication:] method.

Return Value

YES if the file was successfully opened; otherwise, NO.


That's clear enough: if the method can't find the specified file it returns 'NO' - zero. That's very clear. And obvious. And excuse me but it's intelligent in a sort of standard way [outside Cupertino].

Discussion

The appName parameter need not be specified with a full path and, in the case of an application wrapper, may be specified with or without the .app extension, as described in 'Use of .app Extension'. The sending application is deactivated before the request is sent.

Availability

Available in Mac OS X v10.0 and later.


This method dates back to NeXTSTEP of course and at least there it was fine. It's also important to point out that this is a type of 'Unix' thing: Maccies don't normally try to open files with arbitrary apps. That's just not the Mac!

And to tell the truth, this code is still good. But I'm getting ahead of our story.

I followed this crash up by trying it again - repeatedly - and with other apps [what good that did is another matter] and with Runner who uses the same method but not the same calls.

They all crashed - but what's instructive is 'how' they crashed. Following are excerpts from the crash logs.

Version: Runner version 1.8 (1.8.0)

PID:    3123
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000008

Thread 0 Crashed:
0   com.apple.Metadata             	0x9112d7e9 _MDItemMarkAsUsedWithPathAndCatInfo
1   com.apple.LaunchServices       	0x918bcd1d _LSAddRecentNode

Version: Xfile version 1.8 (1.8.0)

PID:    213
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000008

Thread 0 Crashed:
0   com.apple.Metadata       	0x9112d7e9 _MDItemMarkAsUsedWithPathAndCatInfo
1   com.apple.LaunchServices 	0x918bcd1d _LSAddRecentNode

Version: Xscan version 1.8 (1.8.0)

PID:    916
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000008

Thread 0 Crashed:
0   com.apple.Metadata       	0x9112d7e9 _MDItemMarkAsUsedWithPathAndCatInfo
1   com.apple.LaunchServices 	0x918bcd1d _LSAddRecentNode

It isn't our code that's going south and it isn't the NeXTSTEP NSWorkspace code either; but NSWorkspace today is wired genially into Apple's 'unique' launch services which in turn are today wired into Apple's fantastic John Siracusa inspired metadata layer.

I can't express how I feel about this. And what I'd like to do with the entire office complex at One Finite Bloop. Nor can I express how fully WRONG this is.

What you're looking at is SEVERAL layers of code, all of which handle the nonexistent path admirably - and in fact NSWorkspace is prepared (and has been prepared for twenty fucking years) to just return a 'NO'. [A zero.] That's rather easy.

But now the impeccable Apple launch services add a new twist: LSAddRecentNode which dutifully calls MDItemMarkAsUsedWithPathAndCatInfo. And as you can tell from the name this is a bloody beige box HFS function.

And none of these nimrods along the line bother to check if the path is in fact valid? No one in Cupertino has ever heard of defensive coding? Of sanity check code? It doesn't look that way, does it?

At any rate: the ramifications of this incident are staggering. How many more idiot bloopers have these people created? How much more defensive code will ordinary application developers have to add to protect the operating system itself from going pear shaped?

This is a lot like Apple's brilliant solution to the Safari hole: don't change the bloody file system - fix the system level flaw at application level! And leave everyone else's web apps - Firefox, Camino, Omni, et al - wide open for exploit!

Seriously: how much - how badly - do they want to hang onto this archaic fucked up system?

I don't know. I really don't know. Walt Mossberg and others come out and say OS X is head and shoulders above the rest and it certainly looks it and yet Apple have these incomparable pinheads working there.

I'm reminded as well of the anomaly Richard and others discovered when testing Tracker. It was ironically again the same code devolving from the same NSWorkspace method.

And some fucking pinhead decided suddenly 'why should we allow an application to by definition open itself' so that if the same app paths are provided in both fields (internally in the call) pinhead suddenly nixes it all and throws it back.

Rixstep now have protective code in their frameworks for this lame thing. What else happened? We reported it all right - and perhaps a year later someone got back to us. They'd finally got around to fixing it. What good does that do anyone? There are versions of the operating system out there that FUCK UP. And Apple don't fix things per version like that (as others do). So everyone has to have protective code all the time for those who have one of the unlucky versions.

And they kept at us. 'Will you please test it's OK?' And we replied 'it doesn't fucking matter, you IDIOT'. And they'd write back again. 'Please test it, OK?' And finally we just wrote back 'thank you - we tested it and it WORKS PERFECTLY TODAY THANK YOU VERY MUCH'. And that finally shut them up.

Back to our topic: by the time you read this there's a new version of the ACP online to download. What we do now is enable the buttons depending on whether the data will crash Apple's crappy code. This is pretty cool anyway but a slight word of caution.

Odds are you're never going to run into this but it's theoretically possible to click that button and in the nanosecond between the click and the call to Apple's crappy metadata function the file disappears.

You're still going to crash and there's nothing you or anyone can do about it. Until Apple go bankrupt and real programmers come to Cupertino and clean things up.

Cheers.

PS. Now you might wonder at this point why the quote from Doug McIlroy. The key is this bug's been out there for YEARS now - but no one in the world of the beige box will notice because Maccies don't do things that way.

They're the ultimate droolers: they click things; they don't try to open files with an application they themselves specify. They don't go specifying paths on their own. They wouldn't dream of it.

It's as OTDN said: Apple don't understand Unix and they don't like it either. And they have PFYs like Landon Fuller to oversee the code they get from FreeBSD.

And it's like that Rixstep fan expressed it - it's the Ian Malcolm Syndrome(tm). They take a technology - and are happy it saved their pathetic backsides - but they don't understand it and they abuse it.

Whilst the veneer will continue to get more dazzling the underbody will continue to get more tangled, confused, and ultimately ruined and totally useless. It's not a new story but it's totally pathetic and sad still the same. It's happened so many times before - M$ do it all the time - and it's happening again now. Raise your glasses to the former glory of NeXT and the crumbling empire of OS X system code.

The platform needs PROFESSIONAL developers. It has next to none. Apple don't have to make their code better for the few pros on the platform. And almost no one would DREAM of opening a file with an arbitrary application!

First published at the CLIX Exchange. Used by permission.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.