Mac OS X’s Finder: Process of decompressing archives needs to be improved

Posted by Pierre Igot in: Macintosh
September 26th, 2007 • 2:45 pm

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:

Error 9

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.

3 Responses to “Mac OS X’s Finder: Process of decompressing archives needs to be improved”

  1. ssp says:

    Even without the issues you are seeing, operating on several archives on the same hard drive will slow things down unnecessarily and it will extend the time needed until the firs archive has been completely decompressed.

    I recommend The Unarchiver. Not only does it support more formats than BOMArchiveHelper does, it also moves the archives to the Trash when they are decompressed (yay, all the comfort of Stuffit Expander in the mid 90s!) and processes them one by one. You just need to tell the System to use The Unarchiver for your zip archives in a Finder information window and that problem is solved.

  2. Pierre Igot says:

    Thanks for the suggestion (link here for those interested).

    Doesn’t solve the same problem with Finder copies, though.

  3. ssp says:

    Oh totally. The copies remain a mess. But we’ll have to take this one step at a time, I suppose. I also find it less problematic for copies to be honest (possibly because I mostly copy between distinct disks which splits the load across different hardware while decompressing always works with the same source and target, and because to copy a bunch of files I’d select them all and drag them in one go, which just gives a single copy operation, unlike when selecting and decompressing a bunch of zip archives)

    In fact the whole state of any progress indication on the Mac is pretty f*cked up IMO. You can copy, move, empty trash, burn CD, mount disk image, compress, decompress, mount a network volume and get separate progress windows for most of these. Many of them looking quite differently.

    I couldn’t resist filing an ER for that a while ago: a single progress window that appears when needed and just contains all progress bars. Yeah, doing that won’t be easy and it seems quite unlikely it’ll ever be implemented, but I think it’d be a good idea that gives us a cleaner, more obvious and less confusing UI.

Leave a Reply

Comments are closed.