this was a problem before bug 192461 was fixed, and it still occurs with today's camino trunk (2003.03.18.07), on 10.2.4. 0. make sure you have the "automatically open downloaded files" pref turned ON (Navigation - Downloads pref panel). 1. quit and restart camino. 2. go to ftp://ftp.mozilla.org/pub/camino/releases/ 3. click on the link for Camino-0.7.dmg.gz results: the d/l mgr appears and the file downloads fine. StuffitExpander (v7.0) launches, and its status dlg appears... then hangs when expansion progress is nearly complete. if i go to Stuffit Expander, the cursor is the rainbow wheel. if i click on the Open button in camino's dl mgr, then i also get the rainbow wheel. workaround: if i force quit Stuffit Expander, then retry the d/l, it works fine.
oddly, this doesn't always happen for all .dmg.gz files. for example, i didn't have problems when trying to download then expand ftp://sweetlou/products/client/seamonkey/macos/10.x/ppc/2003-03-18-03-trunk/Netscape-MachO.dmg.gz
upgraded to Stuffit Standard 7.0.1, and this is still a problem.
if i don't force quit, eventually i get an error from Stuffit Expander: "An error occurred while expanding the file 'Camino-0.7.dmg.gz" (There is not enough memory to perform the operation). Error #17524"
tried the following tests where the "automatically open d/l files" pref is OFF: a. in the d/l manager, after the d/l has finished, click the Open button: Stuffit Expander successfully expands the file. b. after the d/l has finished, drag the file (Camino-0.7.dmg.gz) onto the Dock icon for Stuff Expander: get a hang again, when expansion is nearly done.
Is the Mozilla trunk also exhibiting this problem? IIRC Simon mentioned Camino had regressed to the bad behavior of decompressing .gz files during download and if StuffIt Expander trusts the file extension and tries to extract the file all bets are aoof. You can check for the decompression during download by seeing if the file written to disk matches the file size from the server.
hrm, i encountered this only *once* with mozilla (nscp build from today); most of the time it succeeds. which makes me think that this might related to timing in some way. ugh. simon checked in a fix for bug 197745, which i'd would've taken care of this. but perhaps what i'm seeing is another issue?
Wow.. I can reproduced the problem when "automatically open d/l files" is enabled. However, I'm not experiencing the problem in Comment #4 with "automatically open d/l files" is turned off. Dragging the file to the stuffit expander dock icon will launch this app and create the disk image properly. No hangs are occuring for me when this is done. Tested with Camino 2003-03-18-08 under 10.2.4.
Looking at sarah's machine, I saw that when Expander hung, the .gz file was truncated; it was smaller than the download should have been.
hrm, this also occurs with the 2003.03.11.07 camino trunkbuild, so this issue predates simon's checkins from 3/17. although he did mention that autoexpand was/has been horked before 3/17 anyhow...
ugh, now i see this using 2003.04.03.03 comm trunk (nscp) bits --so far only once. i was trying to d/l Camino.dmg.gz file (about 7.9MB), but the resulting file on my local disk (Desktop) ended up only 1.3MB in size.
i saw this again with today's nscp build (2003.04.09.10), so this looks like a general mozilla browser issue. only 7.6M of a 7.9M file (Camino.dmg.gz) was downloaded. chris, have you experienced this with netscape (or mozilla)? it doesn't seem to happen as often as on camino, but i think it might have the same cause. out of curiosity, could this be related to bug 161525? fwiw, i have been using a dual-cpu mac...
was able to repro this with a single-cpu G3 running 10.2.4 (today's nscp build, new profile). simon mentioned over chat that bug 161525 is prolly not related.
this is almost certainly a dup of bug 201663. *** This bug has been marked as a duplicate of 201663 ***
this is still a problem with a nscp build from 2003.04.17.03. reopening. :(
This is probably not highly visible if we're not creating broken downloads. We'd consider a fix but we're not going to block the release for this.
Given the age of this initial bug, and that OS X has a built in handler, it's probably time to lay this one down.