Closed
Bug 164924
Opened 22 years ago
Closed 22 years ago
Large .hqx file data not completely transfered via the Download dialog
Categories
(Camino Graveyard :: Downloading, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: chrispetersen, Assigned: sfraser_bugs)
References
()
Details
Attachments
(1 file)
7.46 KB,
patch
|
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
Build: 2002-08-27-05 Platform: OS X 10.2 (6C115) Expected Results: The File that is created should be the size as mentioned in D/L 's Status area (69 MB) What I got: After the transfer is completed, the file's size is around 50 MB and and can't be open in Stuffit Expander. Steps to reproduce: 1) Go to http://download.macromedia.com/pub/dreamweaver/esd/dw_mx_trial_en.hqx. 2) Specify location for file and click Save. 3) Notice the Status area states file as 69 MB. 4) When file is transfered, the status area states file as 50 MB.
Comment 1•22 years ago
|
||
petersen, did this regress recently or has it been a long-standing problem? sounds like's it's related to the other bugs about downloads not thinking they're complete, etc over to brade for a look.
Assignee: pinkerton → brade
Reporter | ||
Comment 2•22 years ago
|
||
I'm working on this now. It try the 0.4.0 release and go from there.
Reporter | ||
Comment 3•22 years ago
|
||
It's not a regression since I can reproduce it in the 0.4.0 release.
Comment 4•22 years ago
|
||
could this be related to bug 164917?
Assignee | ||
Comment 5•22 years ago
|
||
Does the failed download always have the exact same size?
Reporter | ||
Comment 6•22 years ago
|
||
Yes, I always get a 50 mb file size (50.5 MB - 53,047,524 bytes) after the transfer is completed.
Comment 7•22 years ago
|
||
I see the same thing as Chris; downloading goes along fine (averaging 94k/sec or so) and then it hits 50.5Meg and zip... it's done. The resulting file is the same size and stuffit expander doesn't seem to want to expand it. The problem is only for files over a large size which are *.hqx (other file types are fine and smaller *.hqx files are fine). N7 works fine; we should find out if PPEmbed has this problem or not.
Comment 8•22 years ago
|
||
Chris also sees the problem with this hqx file: http://download.adobe.com/pub/adobe/golive/mac/6.x/GL6.0.1_Mac_Client_Updater.hqx (only 8.1 meg)
Reporter | ||
Comment 9•22 years ago
|
||
This works properly in PPEmbed using both urls specified. Seems to be related to file size and .hqx format.
Assignee | ||
Comment 10•22 years ago
|
||
Here's the deal with GL6.0.1_Mac_Client_Updater.hqx: 1. Clicking the link apparently gives an aborted download (at about 6Mb) 2. Context-click->Download link target saves it fine If you look at the resulting files, in the first case, you actually get a .sit file (with a .hqx extension). Fix the extension, and this file unstuffs just fine. In the second case, you get a good .hqx file. What I think is happening is that the server has been configured to un-Binhex on the fly (like some servers gunzip .gz files), but that it still reports the binhexed file size. Or, perhaps we're un-bihexing internally.
Assignee | ||
Comment 11•22 years ago
|
||
So we're actually unbinhexing internally here; we have a nsBinHexDecoders in the steam converters directory. So the issues are: 1. why does chinera un-binhdex, when the others don't 2. if we want to un-binhex, we need to set the new file name and type/creator info.
Assignee | ||
Comment 12•22 years ago
|
||
So I figured this out. The BinHex decoder should not be build for Mac builds; it's intended only as a stop-gap for other platforms, and it's assumed on Mac that helper apps will do the binhex decoding. I have a patch that fixes this (and also addes a missing file for AppleSingle decoding to the build).
Assignee: brade → sfraser
Assignee | ||
Comment 13•22 years ago
|
||
This patch removes nsBinHexDecoder from mac builds, adds nsAppleFileDecoder, and fixes the resulting build issues in nsAppleFileDecoder.app.
Comment 15•22 years ago
|
||
Comment on attachment 97115 [details] [diff] [review] Necko patch to turn off binhex r=sdagley (lose the changes to nsDiskCacheDevice.cpp)
Attachment #97115 -
Flags: review+
Comment 16•22 years ago
|
||
Comment on attachment 97115 [details] [diff] [review] Necko patch to turn off binhex sr=darin (sans cache changes of course)
Attachment #97115 -
Flags: superreview+
Assignee | ||
Comment 17•22 years ago
|
||
Checked into the Chimera branch. Will also check into the trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 18•22 years ago
|
||
Awesome. Verified in the 2002-08-29-05 NB.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 19•22 years ago
|
||
This has now been checked into the Trunk (for Macho Mozilla builds).
You need to log in
before you can comment on or make changes to this bug.
Description
•