Betalogue

Mac OS X’s Finder has a built-in mechanism for compressing and decompressing Zip archives. The command for compressing a file or a group of files into a Zip archive is “Create Archive of ‘X’” (in the “File” menu, in the contextual menu or in the Action menu). There is no command for decompressing Zip archives. You just double-click on them or use the “Open” command, and the Finder automatically decompresses them.

In actual fact, double-clicking on a Zip archive in the Finder launches an invisible background process called “BOMArchiveHelper,” which can be seen in Activity Monitor while it is in action. If you are ever faced with a situation where the whole Finder becomes unresponsive (with the Spinning Beach Ball of Death) because of a problematic Zip archive, you can actually force-quit the “BOMArchiveHelper” in Activity Monitor, and the rest of the Finder will then become responsive again (which highlights the fundamental design issues caused by having such features integrated into the Finder rather than accessible as separate utility applications).

My problem today is not with situations where “BOMArchiveHelper” hangs, however. It is with the way that the Finder handles the situation when you try to open more than one Zip archive at the same time.

The other day, I had downloaded a number of Zip archives off the Internet (about a dozen of them), and I selected them all and double-clicked on the selection to get the Finder to decompress them.

The fundamental problem in such a situation is that the Finder is not smart enough to decompress the various items in the selection in succession. Instead, the Finder does what it always does by default when you double-click on a bunch of files: it tries to open all of them at the same time with their parent applications. Since the parent application of Zip archives is the Finder itself (more precisely, the “BOMArchiveHelper” background process that is part of the Finder), when you double-click on a bunch of Zip archives, the Finder ends up trying to run multiple decompressing processes—one for each Zip archive—at the same time.

There are numerous problems with this. One is that it is an utterly inefficient approach. As you can easily imagine, if you are trying to decompress multiple Zip archives at the same time, this causes a very high amount of wasteful hard drive activity, because the hard drive has to constantly jump from one file to the other. Mac OS X is a fine multi-tasking, multi-threaded operating system, and the Finder itself has had multi-tasking abilities, but this is a prime example where multi-tasking is not a good idea. I am pretty sure that it would be just as fast and not as hard on the hard drive to decompress the files in succession, one after the other.

And the proof that running these decompressing processes in parallel is not a good idea is in the fact that this can actually reveal some of the Finder’s underlying flakiness. Here’s what happened the other day when I was trying to decompress a dozen Zip archives and the Finder tried to do them all simultaneously:

The error message makes it sound like there was something wrong with the Zip archive itself. (This can happen. Some Zip archives can be problematic, no doubt in no small part due to the fact that they can be created with a variety of Mac and PC utilities, not all of which are entirely reliable.) But in actual fact when the other decompressing processes were complete, I simply closed this error message and tried to open the exact same Zip archive in the Finder again.

This time, I was only asking the Finder to decompress this particular file, so it didn’t have to try and run multiple processes at the same time. And the decompressing process went just fine. So obviously this particular Zip archive did not have a “bad file descriptor,” as the error message said. It just so happens that there is a limit to the number of decompressing processes that the Finder is able to run simultaneously. If you try to run too many of them, you end up getting errors like this one, which are effectively bugs in the Finder itself. (This is not the first time I have encountered this bug while trying to decompress Zip archives.)

The bottom-line is that the Finder really should be much smarter, and have some kind of queuing system for such situations, where it would decompress the files one after the other rather than simultaneously.

There are other contexts in the Finder where a similar syste would be appropriate—for example, when you try to copy multiple separate items from one volume to another. If the items are large enough, you can easily start half a dozen separate copying processes in the Finder, which the Finder then attempts to complete simultaneously. Depending on the chosen destination(s) and the read/write speeds of the devices involved, here again the simultaneous processes can cause an inordinate amount of wasteful disk activity, whereas running the copying processes in succession would be much more efficient.

I submitted an “enhancement request” to Apple about this via the ADC a long time ago, and I did get the standard reply to the effect that Apple’s engineers are “aware of the issue” and “working on a solution.” It’s slightly better than to be told than things “work as expected.” It means that at least someone at Apple agrees that this is a design flaw and that the situation could be improved.

Whether it ever actually does get improved, of course, is another matter. But the error described above shows that, even with today’s fast machines, running multiple processes in parallel still is not a good idea and can lead to errors that reveal underlying bugs.

This entry was posted by Pierre Igot on Wednesday, September 26th, 2007 at 2:45 pm and is filed under Macintosh. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.