From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.12-20smp i686; en-US; m14) BuildID: 2000032808 Download latest build with previous nite's mozilla. Attempted to download same mozilla with new browser, and it just keeps GOING. No stopping. Does it everytime. (March 29, 2000) Reproducible: Always Steps to Reproduce: 1. Goto http://www.mozilla.org 2. Download latest nightly build 3. Watch disk space disappear Actual Results: The download went well beyond twice its size and then just stopped. Expected Results: Download fine, like in Netscape. This only happens with that nightly build. I tried other software, like IBM's TopPage, and it downloaded fine.

File downloads have been broken several times in the last couple of weeks. Download the latest nightly and see if you still have the problem. Also, could you download files from other sites or was this a problem just with mozilla.org?

*** Bug 35903 has been marked as a duplicate of this bug. ***

There are several dupes of this reported, bug 35376 and bug 35903 (and I saw at least one more that I can't find now). I think is't safe to confirm this one and get it on the appropriate radars.

*** Bug 35376 has been marked as a duplicate of this bug. ***

I think law has a dup ->law

Hi, I reported 35903 (marked a dup of this bug) which I saw on two Red Hat 6.1 and 6.2 boxes. I just noticed at least in the Linux 2000041316 build that this bug only occurs with downloads faster than about 40KB/sec or so. I couldn't reproduce this bug on the Window Maker (http://www.windowmaker.org) site last night, but today that site's not so bogged down and I am seeing the bug. I can't test for a fix in today's build since I'm having too many stability problems with it. :-(

*** Bug 36091 has been marked as a duplicate of this bug. ***

This bug is different from bug 32741 but they appeared around the same time and I think they're related. (32741 is "Downloading big files over FTP causes huge memory consumptions")

one more thing.. is there a chance the fix for bug 32407 only gagged the real bug? There were a lot of more or less simoultanous ftp error bugs - 32407 was the corrupted download/CRC error one.

seems bug 35417 is also a duplicate - "the one that got away", asa.

*** Bug 37500 has been marked as a duplicate of this bug. ***

*** Bug 35417 has been marked as a duplicate of this bug. ***

*** Bug 36522 has been marked as a duplicate of this bug. ***

Note that this also happens on Windows! Since it's being reported "all the time" I took the liberty of marking some dupes. I believe severity could be rised a notch on this one.

I'm going to paste some of my comments about bug 37500 here, there was another aspect to the behavior that I haven't seen noted here... Moz reported the download speed to be ~7.8kb/s, but when I tried it with another browser on the same connection, it only went at ~4.5 (which is more usual for my connection). Seeing a negative "time remaining" was mildly entertaining. :)

Several duplicates mention "countdown" beyond negative download-time, and also that Moz states erronous download speed. Here a little list of the where observations are made: too big filesize (all) bug 35417 35903 35376 36091 36522 37500 higher d/l speed than expected bug 35417 35903 36091 36522 37500 wrong (negative) time bug 35376 36091 36522 37500 (negative time shows in 36522's attached screenshot) Bug has been reported seen on: MIPS Linux, Windows98 and NT. It can triggers on dowloads via both html and ftp. Is this about failing compression routines? Binary files treated as ascii? That could explain both the seemingly blazing fast downloads and too big filesize as well.

Forgot to mention the most obvious of all: Apart from 35376 (unknown) all reporters have appearantly encountered this bug while downloading via modems.

Not for me. This was over a blazing fast campus connection. (10Mb at peak) I don't have access to a modem, so I couldn't tell you if it would still happen.

I (reported #36522 - dupe of that) was on a cable connection. The very strange thing was it happened for downloading the Linux .tar.gz build but not for the Win32 .zip build - both in Win32 M15.

*** Bug 38241 has been marked as a duplicate of this bug. ***

Putting on [nsbeta2+] radar for beta2 fix.

Move to M18 target milestone.

Adding mostfreq keyword to bug.

I believe this bug is invalid. Mozilla uncompresses .gz files when it downloads them. On such a large file, the gzip compression may half or less the size of the file. This would explain too why the bug only appears when downloading the linux nightly, and not the .zip'd windows one. I've tested a download of this file with 2000053108, on Linux. It actually did not ungzip the file (though a half hour ago, I noticed that it /did/ ungzip another .tar.gz file I had downloaded). The download went superbly, it did not continue going. md5 checksums show that the file downloaded with Mozilla is identical to the one I extracted Mozilla from this morning.

This bug is still valid as of 20000603. E.g. I tried downloading http: //download.macromedia.com/pub/shockwave/flash/english/linux/4.0r12/flash_linux.tar.gz And the download continued past 100% - the number of K downloaded just kept ticking over, and time left went -1. It seemed to keep adding bytes at a constant speed of about 5K/sec. The tar.gz file was broken when I tried using it. Incidentally, the file was reported to be of type "application/x-tar", and did appear to be saved as .tar (not .tar.gz, despite the suggested filename). This seems to be easily reproducible.

bug 41568 is also about the "sidekick" here - gz files unzipping. bug 41560 - "download causes continual stat calls" is.. interesting.

There seems to be more than one potential problem with file download discussed under this bug. I'd like to focus on just one symptom here: this bug is about the problem downloading the URL referenced by this bug: the fact that it never seems to complete, on any platform. That seems to be due to necko calling OnDataAvailable forever and ever (the download code doesn't just start generating it's own data out of the blue, although sometimes it might actually work better that way). So I'm punting this back to Networking to let them figure out what's up with that particular ftp server's responses.

*** Bug 41418 has been marked as a duplicate of this bug. ***

*** Bug 42019 has been marked as a duplicate of this bug. ***

35956 is a dupe, both are assigned to gagan, and both are nsbeta2+. he should mark one a dupe of the other.

*** Bug 41568 has been marked as a duplicate of this bug. ***

*** Bug 42324 has been marked as a duplicate of this bug. ***

sometimes causes segfaults during download; adding keyword; severity++;

This is really the same problem as in 35956. So marking as dup. *** This bug has been marked as a duplicate of 35956 ***

verif. DUP

*** Bug 59324 has been marked as a duplicate of this bug. ***