Closed Bug 162271 Opened 22 years ago Closed 22 years ago

[FIXr]Cannot download specific file types.

Categories

(Core Graveyard :: File Handling, defect, P1)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: harm.ten.napel, Assigned: bzbarsky)

References

Details

(Keywords: dataloss, regression, testcase)

Attachments

(1 file)

make Mozilla to download *.Z -files
280 bytes, patch
dwitte
: review+
bzbarsky
: superreview+
dbaron
: approval1.3b+
Details | Diff | Splinter Review
We have an internal testcase repository at Oracle and customers upload compressed files sometimes with the extension .Z , for example rda.tar.Z (note the capital 'Z' as the compress utility on Unix creates it). When doing -right mouse- , -save link target as- the download manager window reports 'Finished' immediately with the correct file size, however the file is not on my disk! This bug happens with at least the .Z extension.
what build ID are you using ?
This is build 1.1b . I suggest creating a compressed file with .Z extension, put it on a http server and try to download it.
Steps to reproduce a problem (might be similar to yours): - load http://www.apache.org/dist/httpd/ , - simple click (not right click + save as) on apache_1.3.26.tar.Z , - cancel download, - simple click again on the same file, - error message: the file can't be downloaded, etc. This is with build 2002081209 on Win2k (trunk). (subsequent error: http://httpd.apache.org/dist/httpd/ can't be reloaded anymore)
I cannot reproduce it, but I use Mozilla 1.0 behind a Squid 2.4. Neither steps in comment 0 nor comment 3 reproduce it.
I checked again and it still reproduces, when I normal (left) click on the url, a popup comes up: C:\DOCEME~1\HNAPEL~1.NL_\LOCALS~1\TEMP\9yo2tx5w.Z could not be saved, because the source file could not be read. Try again later, or contact the server administrator. (It works with IE or netscape 4.79 so the file can be read). The specific URL is (although you can't reach it, it may give you a clue): http://ess8.us.oracle.com:8001/gtcr-dir/Netherlands/2346378.996/
The filename is RDA.28395.rda.tar.Z (maybe it's all the dots...)
harm, I get the same error message in comment 3.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
*** Bug 162647 has been marked as a duplicate of this bug. ***
Well, it seems to be a windows 2000 related bug. Following comment #3, I cannot reproduce the bug ! Using trunk build 2002081308 - WinXP.
dup at #8 was with win98 and the file was an .exe (maybe worth a check at mime type) IMO the trigger scenario is: a busy server, download ends badly during first attempt then you can't download it at all
In answer to comment #10 Well, IMO too, this is the true story of this bug :-) That was also my conclusion for bug 162647 you marked as dup of this one !
I have reproduced this with 2002-08-12-21 Linux. After following the steps from comment 3 I get the same error, "/tmp/z0egdhmp.tar could not be saved, because the source file could not be read. Try...". With 2nd download, Mozilla added 2 headers to the HTTP request (used a sniffer): Range: bytes=229376- If-Range: "cbca3-37df75-746f6f00" With the 2nd download the server replied with a "HTTP/1.1 206 Partial Content", followed by headers and content.
OS: Windows 2000 → All
*** Bug 165718 has been marked as a duplicate of this bug. ***
*** Bug 165716 has been marked as a duplicate of this bug. ***
Also reproduces with 1.1 on Win2k SP3 with URL ftp://dl.xs4all.nl/pub/mirror/linuxberg/files/netauth43d_linuxlibc6.tar.Z (I have no permission to put this URL in the URL field.)
On XP Pro, I cannot reproduce the problem with this URL - the file is however saved with a .tar.Z.tar extension.
WFM 1.1 Linux 686
still confirmed on 1.2a (build 2002901014)
wfm using build 2002091208 on Win2k (trunk).
Not here (same build) - when downloading, Mozilla seems to add a .tgz extension to the file when requesting it from the webserver.
*** Bug 172601 has been marked as a duplicate of this bug. ***
*** Bug 173723 has been marked as a duplicate of this bug. ***
*** Bug 173755 has been marked as a duplicate of this bug. ***
*** Bug 173726 has been marked as a duplicate of this bug. ***
Isn't this a duplicate of bug 171441?
Confirmed also - 2002101015, Win2kSP2, freshly created profile.
Yes, this and Bug #171441 are the same thing. Now sure which should be duped against which.
QA Contact: sairuh → petersen
Duping against 171441. I know this is older, but 171441 is busier and there is no point saying 'this should be duped' and not doing it. *** This bug has been marked as a duplicate of 171441 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Are you going to mark all the other duplicates of THIS bug also as duplicates of bug 171441 ?
> Are you going to mark all the other duplicates of THIS bug also as duplicates > of bug 171441 ? That isn't necessary. There is no benefit of doing it.
wfm <ftp://dl.xs4all.nl/pub/mirror/linuxberg/files/netauth43d_linuxlibc6.tar.Z> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021014 Phoenix/0.3 most people tend to install over old versions of mozilla. Even though the installation instructions and release notes clearly instruct people not to do this. There are currently a few bugs which are the result of this. One is fixed by deleting compreg.dat. The other is fixed by deleting mismatched .xpt files (in short, delete cleaning out your components directory and reinstalling a fresh mozilla). Someone complained that simply deleting compreg.dat didn't help them. please try installing into a fresh directory or cleaning out the components directory and then reinstalling mozilla.
Based on http://bugzilla.mozilla.org/show_bug.cgi?id=171441#c155 I am reopening this bug. Apparantly, deleting COMPREG.DAT doesn't always fix this bug, unlike Bug #171441 where it always does.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I am the "someone" you mention, David. When "upgrading" Mozilla I always delete my entire Mozilla directory and then unzip the .zip file's contents into the Mozilla dir. I tested the URL both with a new profile, and with Phoenix 0.3 (separate directory, of course!). In both cases I cannot download the file - the famous "xxxxxxxx.tgz could not be saved, because the source file could not be read."
Before someone dups this to Bug #171441 again. This bug is for the instances where deleting COMPREG.DAT does NOT fix the problem. Also, Bug #171441 is Windows only, while this one covers more than one OS (Yes, I do consider all the various Windows flavours to be one OS).
Seems to be dup of 160755
Since no objections... *** This bug has been marked as a duplicate of 160755 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
I said 'specific file types' with compressed (.Z) being an example not knowing this is limited to compressed files only. Hope resolution soon, thanks.
vrfy
Status: RESOLVED → VERIFIED
Ultimately: http://www.gzip.org/zlib/zlib_faq.html#Z-files seems to be the problem, see Bug 160755
This can simply be fixed by just add "Z" to nsExternalHelperAppService.cpp 157 static const char* const nonDecodableExtensions [] = { 158 "gz", 159 "zip", "Z", //Bug 162271 160 0 161 }; see Bug 160755 for details
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
CC'ing bzbarsky
reviews? (and could someone check this in?)
Comment on attachment 112625 [details] [diff] [review] make Mozilla to download *.Z -files r=dwitte, per request of bz
Attachment #112625 - Flags: review+
Attachment #112625 - Flags: superreview+
taking.
Assignee: blaker → bzbarsky
Status: REOPENED → NEW
Component: Download Manager → File Handling
Priority: -- → P1
Summary: Cannot download specific file types. → [FIXr]Cannot download specific file types.
Target Milestone: --- → mozilla1.3beta
Severity: normal → critical
Keywords: dataloss
Comment on attachment 112625 [details] [diff] [review] make Mozilla to download *.Z -files Simple patch, fixes a dataloss bug. Could we take this for 1.3b please?
Attachment #112625 - Flags: approval1.3b?
Attachment #112625 - Flags: approval1.3b? → approval1.3b+
Fixed. Thanks for the patch, guys!
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Using 1.3b. ftp://dl.xs4all.nl/pub/mirror/linuxberg/files/x86-linux-glibc2.1-17.0.0.2.3.tar.Z is saved to my disk as x86-linux-glibc2.1-17.0.0.2.3.tar.Z.tgz (when clicking file and selecting Save to disk). The file 'type' is still .Z however, which confuses decompressing software. Apparently Mozilla still tries to do something "intelligent" when downloading this file. Should this bug be reopened or is this a separate issue?
Probably a different bug, but I can confirm this. Not the fact it saves it as a .tgz, but that mozilla tries to save files with the extension of a file I saved before. Can't find any regularity in it, except from the fact it sometimes happenes. Currently, I get .exe files to sometimes save as an .exe.msi file.
That has nothing to do with this bug and everything to do with a security hole in windows that we're papering over in a ham-handed way. There are dozens of bugs on various aspects of it, if you look for them.
*** Bug 193745 has been marked as a duplicate of this bug. ***
*** Bug 163715 has been marked as a duplicate of this bug. ***
*** Bug 193978 has been marked as a duplicate of this bug. ***
*** Bug 185872 has been marked as a duplicate of this bug. ***
Marking verified on Win32 2003-03-13-04 trunk and OS X Mach-o 2003-03-13-03 trunk builds.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: