Closed Bug 385592 Opened 17 years ago Closed 11 months ago

Download produces corrupt files

Categories

(Toolkit :: Downloads API, defect)

defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: ok34, Unassigned)

Details

User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.2) Gecko/20070306 SeaMonkey/1.1.1 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.2) Gecko/20070306 SeaMonkey/1.1.1 Downloading from the mentioned URL (latest build 1.1.2 of Seamonkey for OS/2) produces broken files that do not pass the built-in integrity checks. Each time the damaged block is on a different location within the file. I tried this three times in a row, and each time a different .xpi was reported to be broken and the installation terminated. Binary comparison of the three downloaded files showed that they differ. Reproducible: Always Steps to Reproduce: 1.Download from above URL 2.Compare downloads or start install 3. Actual Results: .EXE is broken. Expected Results: .EXE should not be broken. Since I have been downloading so many other files with this version of Seamonkey (Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.2) Gecko/20070306 SeaMonkey/1.1.1) I do not suspect this to be a problem of the client, but a problem of the server.
Assignee: nobody → justin
Component: *.mozilla.org → FTP: Mirrors
OS: OS/2 → All
Product: Websites → mozilla.org
QA Contact: other-mozilla-org → justdave
Hardware: PC → All
Version: unspecified → other
Oops, wrong component. I can't reproduce this on the 2 internet connections I have convenient access to atm with wget. Keep in mind that releases.m.o is not a single server and I'm not sure how many I tested against. Also, the checksums matched the md5sum I grabbed from https://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.1.2/contrib/seamonkey-1.1.2.en-US.os2.MD5SUMS
Assignee: justin → zach
Component: FTP: Mirrors → FTP: Staging
QA Contact: justdave → preed
Assignee: zach → justin
Component: FTP: Staging → FTP: Mirrors
QA Contact: preed → justdave
I'm seeing similar random file corruption with http downloads through a RF internet connection using a Waverider EUM3005 RF Modem. If I download large files, the downloads tend to be corrupted if I use Firefox or Seamonkey. IE and command line ftp produce clean downloads. The download errors occur under both Linux and Windows XP. I've also encountered problems with a Windows XP Thunderbird automatic update being corrupt.
This annoying bug continues to exist in Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.5) Gecko/20070721 eSeaMonkey/1.1.3 Also, it does not only show up on releases.m.o, but on several other servers as well. Making several downloads of the same file and binary comparing them reveals that at some point (e.g. OFFSET 40102C8h) the file contains several 00 instead of the correct file content. So far I could not figure out similarities between file servers affected and or files affected. Except for one: It only happens files that are large (40 MByte and greater [guessed]). Today I had five of these download corruptions (unfortunately they were all for paid content, so I cannot post the URLs). Therefore raising severity to MAJOR. Removing misleading URL r.m.o. This is not a r.m.o. issue, but a Mozilla suite issue.
Severity: normal → major
Component: FTP: Mirrors → General
Product: mozilla.org → Mozilla Application Suite
Version: other → SeaMonkey 1.1 Branch
Assignee: justin → general
QA Contact: justdave → general
The bug still persists in Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.11) Gecko/20071129 SeaMonkey/1.1.7 (PmW). Annoying!
I see the same issue in Firefox as well.
Some experimenting showed that the bug seems to be only showing when downloading more than one very large file. Downloading only a single large file at a time seems to be a workaround, although an impractical one.
I have the problem in Firefox with single downloads. Note that this is through an RF modem that may have a percent or two of packet loss.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming this. Sunday I had my first single download that was corrupt...
At some point IE and Windows automatic update started to have problems as well. ftp has continued to work correctly. I finally tracked this down. The problem is related to the SPI (Stateful Packet Inspection) firewall in my Netgear router. This seems to be a pretty common Netgear issue across multiple products. http://forum1.netgear.com/showthread.php?t=6662 After turning off SPI my download issues went away. Now works for both Kubuntu Linux (Hardy Heron) and Windows XP.
(In reply to comment #9) > At some point IE and Windows automatic update started to have problems as well. > ftp has continued to work correctly. > > I finally tracked this down. The problem is related to the SPI (Stateful Packet > Inspection) firewall in my Netgear router. This seems to be a pretty common > Netgear issue across multiple products. > > http://forum1.netgear.com/showthread.php?t=6662 > > After turning off SPI my download issues went away. Now works for both Kubuntu > Linux (Hardy Heron) and Windows XP. > If it isn't a Mozilla bug but a Windows bug or a Netgear bug, then I suppose this bug should be RESOLVED INVALID and the problem reported, if possible, to whoever is responsible for the faulty product.
This neither a Windows nor a Netgear bug - Since I don't use Windows, and I do not have a netgear router. My router is a Siemens, and the operating system is OS/2.
Oliver, Can you turn off your router's firewall as a test?
Assignee: general → nobody
Component: General → Download & File Handling
QA Contact: general → download
Sure. I will report the results here.
With current Seamonkeys the problem has somewhat lessened, but did not go away completely. Just yesterday saw it happen again, but I had no chance to repeat the download in question with firewall turned off. I will try to force the occurence of the error and report here.
Component: Download & File Handling → Download Manager
Product: SeaMonkey → Toolkit
QA Contact: download → download.manager
Version: SeaMonkey 1.1 Branch → unspecified

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(mak)

too old bug to debug.

Status: NEW → RESOLVED
Closed: 11 months ago
Flags: needinfo?(mak)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.