Panther’s Finder: The problem with integrated features
Posted by Pierre Igot in: MacintoshApril 19th, 2004 • 7:06 am
In Panther, the Finder includes an archiving/compression utility that attempts to replace third-party products such as Aladdin’s StuffIt. The utility consists of a command called “Create Archive of X” that is accessible either through the “File” menu in the Finder or through the contextual/Action menu available whenever something is selected in a Finder window. Using this “Create Archive” command with a selection of files or folders creates a Zip archive of the selection using the standard, Windows-friendly “.zip” format.
(In effect, this feature cannot act as a substitute for StuffIt, because it totally ignores resource forks and therefore renders a number of Mac files unusable. But that’s another issue…)
The decompression/expansion side of things is handled through the “Open” command in the Finder, which, if the item that you attempt to open is a Zip archive, causes a window to pop up indicating that the Finder is in the process of decompressing the archive.
In other words, this archiving/compression utility is fully integrated. It is not a separate application in Mac OS X. It is — or at least it looks like it is — part of the Finder application itself.
The problem with this approach surfaces whenever there is a problem with a Zip archive. For example, earlier today, I attempted to download a Zipped PDF file from this web site. The file was approximately 7 MB.
About halfway through the downloading process (in Safari), something caused an interruption. Safari, being a not particularly smart application when it comes to handle downloads, just assumed that the downloading process was complete and listed the file in its “Downloads” window as a completed download.
Out of curiosity (even though I knew very well that the archive was not complete), I double-clicked on it in the Finder in order to “open” it, i.e. start the decompression process.
The following window popped up in the Finder:
In the beginning, it had a “Cancel” button. The candy bar animation went on and on, with no sign of progress. So I clicked on the “Cancel” button. Unfortunately, all that this did was to make the “Cancel” button disappear. But the cancellation itself never took place.
Half an hour later, the window was still there, with the candy bar animation rotating endlessly. That’s when I took a snap shot of it with Snapz Pro X.
I opened the snap shot in Photoshop and noticed that the file was called “BOMArchiveHelperSnapz001.tiff”. Normally, when Snapz Pro X takes a snap shot, it automatically uses the name of the corresponding application as part of the name of the file. So I expected a file named “FinderSnapz0xx.tiff”. But this file name clearly indicated that the integration of the archiving/compression utility in Panther’s Finder was just a façade and that it was, in fact, handled as a separate process. When I checked in the Finder’s “Window” menu, this particular window was not listed — another sign that it wasn’t really part of the Finder application in the interface.
So I launched Activity Monitor and asked it to display “All Processes”, and then typed “BOM” il the Filter. Sure enough, the following process showed up:
The process was still going on strong, consuming up to 90% of my CPU power. (Fortunately I have two CPUs…) And it was listed as a process whose parent was the Finder.
I clicked on the “Quit” button in Activity Monitor — et voilà. The process was gone, and my CPU usage was back to normal.
The moral of all this? Integration is cool, but only if potential problems are handled gracefully and efficiently. This is not the case with the archiving facility in Panther’s Finder. From Mac OS X’s point of view, it is part of the Finder, but it is in fact a separate process, not listed in the Finder’s “Window” menu even when the window is visible. (In fact, if you click on this window with the candy bar animation from another application, Mac OS X doesn’t switch to the Finder and displays the window as part of the interface of your current application!)
As my example demonstrates, things can go wrong, and unfortunately they can go wrong to the point that a trip to Activity Monitor is required. Should ordinary users really have to know how to do all this? I don’t think so… First of all, when the user clicks on “Cancel”, it should work. Secondly, when things go really wrong, the one thing that Apple can reasonably expect users to know how to do is to “force quit” an application. The problem is that BOMArchiveHelper might be a process, but it is not an application and is therefore not part of the Force Quit interface. You can force quit the entire Finder application, which will kill its subprocesses, but it’s hardly a practical solution, and will lead to some unnecessary data loss (position of open windows, etc.).
All in all, it could be argued that Apple should have provided the archiving facility as a separate utility rather than through this integrated behaviour. (The same thing goes for FTP connections, which are just as likely to go wrong, if not more.)
April 19th, 2004 at Apr 19, 04 | 7:24 am
I thought the BOMArchiveHelper is able to put resource forks into the archive – one needs an appropriate decompression software to decompress these specially formatted archives correctly though (i.e. StuffIt 8.x).
April 19th, 2004 at Apr 19, 04 | 10:33 pm
Definitely mostly a GUI thing as far as I am concerned. The fact that clicking on the “Cancel” button didn’t result in proper cancellation is a concern that goes beyond the GUI, but the rest of my problems were with the GUI itself. The archiving utility should be properly integrated into the Finder or treated as a separate application.
The thing to understand about my playing dumb and trying to open a file that I knew was incomplete is that there were absolutely no clues in the UI about the fact that it was incomplete. If I hadn’t paid attention to the download size (7 MB) specified in Safari when the downloading process started and noticed the difference with the finished download (3 MB), and if I had just let Safari do its thing, I would have had no clue that the file was not complete. This is, in part, due to the fact that, as soon as a file has the “.zip” extension, it’s considered a properly formed Zip archive. So in a way the problem is also due here to Apple’s decision to adopt file name extensions as a standard way to describe a file in OS X. There should be something in the way downloaded files are handled that ensures that, if the download has not been completed, the file is not considered a properly formed file. OS X doesn’t have such a safeguard.
(On the other hand, Speed Download 2, which I normally use for my downloads, does have such a mechanism: Incomplete downloads have the extension “.incomplete” added to them, and the extension is only removed once the downloading process is complete.)
It’s a simple thing that SD2 does right and OS X does wrong (or at least does without sufficient safeguards).
April 19th, 2004 at Apr 19, 04 | 4:48 pm
I believe this feature is not Apple supplied. At least not in the sense that Apple created the program. This is a archive program all Unix variants have, hence the lack of resource fork support. Apple did add the GUI hooks allowing the use without going to the Terminal and using the command line. So while they didn’t create the program there are still areas they need to correct for cases like yours. But the problem is in the GUI front end.
I do like the idea of you knowing it was an incomplete file, but you still tried to unzip it. It’s like the concept MP3 that people were downloading to see how a trojan horse could affect their system. Almost like poking a wasp nest. But that’s how problems are found most often, people doing things that programers and developers assume they won’t do. I’m sure a novice computer user would try to open a file if their browser said was done. Many wouldn’t check the size to see if it was the correct size. But I’m sure no one at Apple asked, “what would happen if someone tried to open an incomplete file?” They just assumed no one would try.
It’s just like people assuming everyone knows what a right-click means. However having worked in tech support, I remember having to explain it to many people. It’s an assumption of knowledge based on what you know.
April 19th, 2004 at Apr 19, 04 | 10:37 pm
ozean: I just tried the following experiment: I took a Mac OS 9 application that very likely contains a resource fork (Scherlock 2), compressed it with “Create Archive”, and opened it. Mac OS X decompressed it and launched it properly in Classic and it seems to be running fine. In other words, it does look as if the “.zip” format used by Apple preserves resource forks… as long as you use Mac OS X’s Finder to decompress the archive. Interesting.
April 20th, 2004 at Apr 20, 04 | 2:46 am
Usually, SD2 correctly flags the download as “failed” and never converts the “.incomplete” file into the actual file.
I guess the problem here is that Safari’s system doesn’t work reliably, presumably due to a misinterpretation of the connection failure as completion of the download. But given that Safari was correctly able to register, when it started the downloading process, that the full download was going to be 7 MB, it never should have made the mistake of assuming that the 3 MB partial download was complete. It’s a simple matter of putting 2 and 2 together.
April 20th, 2004 at Apr 20, 04 | 2:04 am
Pierre, Safari does have a system for indicating incomplete downloads. It creates a package with a .download extension and an icon that displays a progressbar. When the download is complete, it trashes the package and replaces it with the actual downloaded file. If you stop a download, the package is left behind and you can extract the partially completed-download by doing a Show Package Contents in the Finder.
But if Safari mistakenly thinks the download <em>is</em> complete when it really isn’t, I don’t know how it treats the .download package. I guess from your example it treats it like a completed download and you get the partial file. How does Speed Download 2 handle such a case?
April 20th, 2004 at Apr 20, 04 | 10:03 pm
Thanks for the clarification about resource forks in Zip archives. This will definitely make me somewhat more comfortable recommending to people that they use this feature for file compression purposes… although the problem with the incomplete file archive goes against this.
As for proper browser support for file downloading, I gave up on that a long time ago. I try to use Speed Download 2 as much as possible.
April 20th, 2004 at Apr 20, 04 | 3:34 am
Just wished to point out that it definitely handles resource forks correctly, by creating an extra folder inside the zipped file containing the resource forks as data.
Double-clicking the .zip file also will restore the resource forks correctly, as will decompressing with the latest Stuffit Expander (8.0.2). Previous versions of Stuffit will, however, not know about the extra folder and fail to rejoin the forks correctly.
Unzipping a partial file will, in my experience, usually – but not always – hang or crash both the “BOMArchiveHelper” and Stuffit Expander; I’m not sure whether this is a problem with the .zip format itself.
AFAIK the HTTP protocol definition says the user should be notified if the content-length declared in the message header differs from the actual downloaded content, but so far I haven’t seen a single browser actually implement this; perhaps mismatched lengths are so common you’d be deluged with error messages? ;-)