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

Home » Learning Curve » ACP Guru

Highway -41 Revisited

Another look at Joel Bruner's ACL bug discovery.

Get It

Try It

CAMBRIDGE (Rixstep) — Joel Bruner's discovery of a pernicious ACL bug in both Finder and Path Finder caused a bit of a stir. What many people evidently can't understand is how other utilities such as Rixstep's Xfile and the command line variants could escape unscathed.

Another greater question is why there have to be separate and parallel ways of doing the same thing in OS X. And finally: what kind of code are Finder and Path Finder using to once again get into so much trouble?

Anandtech concluded that the APIs for Apple's OS were in fact a 'hodgepodge', the main reason for this assessment being that Apple were reluctant to scupper their old 'beige box' APIs.

Long Live Carbon!

The 'alternative' Apple API known as 'Carbon' was an attempt to get developers with considerable code to 'upgrade' to OS X swiftly. Carbon was never meant as more than a transitional solution. Apple wanted to nudge rather than force developers to use the same consistent API used back in the days of NeXT. Similar things had happened earlier in the world of Microsoft.

But people didn't abandon Carbon as they were supposed to. They kept on doing things like this. And some of the worst culprits after Adobe (of course) and the assorted Beige Box Idiots™ who weren't acquainted with Steve Jobs or NeXT were the Apple engineers themselves. Unbelievably enough.

There were lots of good things emanating from Cupertino but a file manager people didn't laugh at wasn't one of them. And year after year cries were heard to put more 'beige' back into 'TFF' and simultaneously discreet whispers that perhaps this most crucial of native applications should also run the system's native API?

OS X 10.6 'Snow Leopard' was supposed to finally kill off Carbon forever. Finally. But did it?

Back to Brunerd!

Scoot on back to the blog of Joel Bruner, a network administrator working with a lot of OS X client and server machines. Bruner's the one who accidentally discovered the latest in a long line of embarrassing 'kindergarten programming' bugs in Apple's flagshit 'file browser application'. This work was covered recently at Rixstep in two articles linked below.

Joel's since had comments from a number of visitors. Pay attention to the fourth comment.

Dragan said,
March 24, 2011 @ 3:22 am

'What's interesting is what calls is PathFinder using?'

Path Finder uses standard calls from Mac OS X File Manager core service, more particularly FSCopyObjectSync() and FSCopyObjectAsync(). The same are apparently used by Apple's Finder. So these calls seem to be root of the problem. I suppose XFile [sic] uses cp, but I can't be sure about that.

I will make sure to file a bug report at Apple's Bug Reporter site and let you know. The more people do it, the more eager they will be to fix it (I guess).

The poster seems to be from the Path Finder developer team. The poster refers to Apple's 'core service' for file management. But that's just another cute word for 'Carbon'. Apple's 'Carbon' reference is where both calls are documented.

http://developer.apple.com/library/mac/#documentation/
Carbon/Reference/File_Manager/Reference/reference.html

You can find the direct link for FSCopyObjectAsync() here and the direct link for FSCopyObjectSync() here. Have a look.

Neither NeXTSTEP nor Unix have data types such as FSFileOperationRef, FSRef, CFStringRef, OptionBits, FSFileOperationStatusProcPtr, CFTimeInterval, FSFileOperationClientContext. None. That's all Mac-specific. Carbon. Carbon code isn't portable. And from what we've seen from Joel Bruner's research, it's a mess too.
That code's been deprecated for nearly ten years, the demise of which has been a cause for celebration in intelligent developer circles. Using that code only brings the OS X platform down.
Carbon code invariably crashes more often, hangs more often, and makes the OS vendor Apple look like crap.
Cocoa code is efficient and has an extremely easy learning curve. There's no excuse for still not getting with the programme after the system's been on the market so long. Particularly not for Apple either.

Several links are provided below for further study. But try to remember all the scares and scandals over the years - 'massive data loss', 'Oompa Loompa', 'Opener', 'system login items', and all the rest. Those weren't endemic Unix flaws. Unix was and is fine.

Those were flaws introduced by Apple code that wasn't supposed to be there.

Any developer who 'supposes' Xfile might be using 'cp' is probably a Carbon developer and part of the problem.