Your browser may have trouble rendering this page. See supported browsers for more information.

|<<>>|134 of 265 Show listMobile Mode

Non-essential Drive Failure in the OS X Finder

Published by marco on

The Finder in OS X is a notoriously old, cantankerous piece of software. With every major operating system release from Apple, we wait with bated breath for the announcement of a long-awaited replacement. There are two primary reasons for this: support for external drives, like CD- or DVD-players and support for networked volumes. In both cases, OS X, ostensibly a multi-tasking powerhouse, capitulates completely to the whim of the external resource, slowing to a crawl that is often nearly indistiguishable from a complete system freeze. You only know you haven’t gotten a kernel panic because you don’t see the nearly-friendly multi-lingual suggestion to reboot your computer at your earliest convenience and you can still hear your CD-player merrily thrashing its way through a patch of bits it has no chance of being able to read. The only way that connecting to a network volume that is not currently available differs in any way is that there is less thrashing.

What is so damned hard about making connecting to a volume asynchronous? It took Windows six generations, but it finally got there—more or less—in Windows Vista. OS X users are still waiting for a day when they can connect to a remote volume without having to watch it happen. And what is it about a CD-player that makes it have such a low-level interrupt on the operating system? Copying files from illegible or recalcitrant media should just take longer, not stop all other activity on the machine.

If you really want to have some fun, trying copying data from portable media, like a CD, then browse around the CD at the same time, perhaps clicking an image or two to have the Finder grab a preview of the file. It will be music to your ears as the Finder executes what seems like dozens of individual read-operations to grab those 150KB off of the disk while at the same time heroically continuing to copy files from an entirely different part of the CD. Hasn’t this problem been solved? OS X doesn’t realize that the request for data in two different place on a CD will likely be handled much more slowly when addressed using the same algorithm as that used for much faster devices, like hard drives. It should. It should know that sequential reading is much faster on a CD, so it should pause the long-running operation, grab the tiny scrap of data needed to show the preview—in one read, if possible—then continue the long-running operation again. The OS doesn’t even have to determine heuristically which operation takes longer; it just has to increase the time-slice afforded to the two requests to something much larger in order to avoid thrashing. This isn’t rocket science.

When OS X was back up and running, it informed me that a crash had occurred, but utterly failed to apologize for it. It did, however, offer to let me make a bug report, so I did[1]:

“Copying data from a CD with which the CD player was clearly having problems. The Finder locked up and all other programs responded extremely slowly.[2] After an interminable timeout, the Finder showed an error message and the system was back on its feet. I pressed the “eject” icon next to the CD in the Finder and the system crashed.

“Cocoa Finder please.[3]

“Failing that, a modern Finder/OS that doesn’t lock up because of a non-essential drive failure will do (this goes the same for networking support, while you’re at it).”


[1] After, of course, manually connecting to the wireless network to which this Mac happens to always be connected. This despite the fact that it is told to automatically join its preferred network. It can’t do this, however, because it utterly fails to remember my password for this network, no matter how many times I’ve told it to add the password to my keychain. But that’s a rant for another day.
[2] I was generous here, as slowly in this case means that it took 30 seconds for each typed letter in a web browser’s address field to appear on screen.
[3] The Cocoa Finder is the fabled replacement for the Finder, written in the much more modern OS X API called Cocoa (as most other Apple applications now are) rather than in the nearly-deprecated API called Carbon, which has it’s roots as an OS 9-compatibility library.