If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

autoexpanding initially fails, Stuffit Expander hangs (truncated file)




File Handling
15 years ago
a year ago


(Reporter: sairuh (rarely reading bugmail), Unassigned)



Firefox Tracking Flags

(Not tracked)





15 years ago
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.

Comment 1

15 years ago
oddly, this doesn't always happen for all .dmg.gz files. for example, i didn't
have problems when trying to download then expand 

Comment 2

15 years ago
upgraded to Stuffit Standard 7.0.1, and this is still a problem.

Comment 3

15 years ago
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"

Comment 4

15 years ago
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.

Comment 5

15 years ago
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.

Comment 6

15 years ago
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?

Comment 7

15 years ago
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.

Comment 8

15 years ago
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.

Comment 9

15 years ago
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...

Comment 10

15 years ago
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.
Severity: normal → critical

Comment 11

15 years ago
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

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...
Assignee: sdagley → sfraser
Component: Downloading → File Handling
Keywords: hang, nsbeta1
Product: Camino → Browser
Version: unspecified → Trunk


15 years ago
Summary: autoexpanding initially fails, Stuffit Expander hangs → autoexpanding initially fails, Stuffit Expander hangs (truncated file)

Comment 12

15 years ago
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.

Comment 13

15 years ago
this is almost certainly a dup of bug 201663.

*** This bug has been marked as a duplicate of 201663 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 14

15 years ago
this is still a problem with a nscp build from 2003.04.17.03. reopening. :(
Resolution: DUPLICATE → ---

Comment 15

15 years ago
and nominating.
Flags: blocking1.4?

Comment 16

15 years ago
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.
Flags: blocking1.4? → blocking1.4-

Comment 17

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
still happens?
QA Contact: chrispetersen → file-handling


9 years ago
Assignee: sfraser_bugs → nobody

Comment 19

9 years ago
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.


a year ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.