Closed
Bug 168846
Opened 22 years ago
Closed 15 years ago
when download is incomplete/truncated, full size and "finished" should not be reported
Categories
(SeaMonkey :: Download & File Handling, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 142666
People
(Reporter: sroland, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 WebWasher 3.0 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 WebWasher 3.0 Sometimes, downloads are not completed correctly, instead it seems they are aborted at some time, and the file is truncated. The download manager will however show Finished under Progress and will indicate under Transferred that all bytes were received. This seems only to happen when using slow (modem) connections, and especially if there is other network traffic (i.e. multiple downloads and/or surfing), so I'd assume there was a timeout or packet loss or something similar. Reproducible: Sometimes Steps to Reproduce: 1. Initiate Download (preferably more than one big files) using a slow connection 2. Browse the web/read email (to increase network traffic) 3. Actual Results: File got truncated at 34MB. Download Manager reported the whole file (96MB) was transferred and said finished. Expected Results: File should have downloaded completely or there should have been an indication that it couldn't complete due to an error which apparently happened (ideally it should be possible to resume aborted/cancelled downloads, but this is a different issue which is already covered by other bugs).
Comment 1•22 years ago
|
||
I'm seeing the same thing, while trying to download large zip files (120MB ish) using the 1.2a build (on Win2k). Initially I assumed it was due to having many of these large files downloading all at the same time so I repeated the download with just a single file. The download starts out OK, with the progress incrementing as expected. Then upon reaching around 47MB the download manager announces that the download is finished and shows the total sizes as downloaded. Going and checking in explorer shows a 47MB file there (which obviously winzip refuses to open). Off to do some more testing after hitting commit on this...
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 2•22 years ago
|
||
Seeing the same thing on 1.2b, win2k. There are two seperate bugs here, 1) downloads are truncated sometimes 2) if a download is truncated then the the filesize downloaded changes to the expected filesize rather than the actually downloaded filesize. Also the status should probably be "aborted" or "truncated" rather than "finished".
Comment 3•22 years ago
|
||
downloads being truncated sometimes is unfortunately inevitable on the internet - connections are not 100% reliable. however, if the download does not reach the full size, it is a bug that mozilla reports the size of the original file, rather than the size of what was downloaded. think this merits confirming, particularly as there are dupes.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: downloaded file is truncated, but download manager reports download has finished → when download is incomplete/truncated, full size should not be reported
Comment 4•22 years ago
|
||
*** Bug 182609 has been marked as a duplicate of this bug. ***
Comment 5•22 years ago
|
||
*** Bug 180275 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Summary: when download is incomplete/truncated, full size should not be reported → when download is incomplete/truncated, full size and "finished" should not be reported
Comment 6•22 years ago
|
||
*** Bug 174916 has been marked as a duplicate of this bug. ***
Comment 7•21 years ago
|
||
same problem with 1.3 on win2k. the window should at least give the amount that was transferred. ie, 34000KB of 48000KB.
Comment 8•21 years ago
|
||
Same thing on 1.4b in Win2k. Happens pretty consistently when attempting to download ISOs from linuxiso.org. Can't get more than about 15mb before it happens.
I am not sure if bug 199745 and bug 122595 is related/same to this bug. I think this bug should be changed for all OS since it appears to happens on both windows and Linux. The severity should also be updated to major since this component is not doing what it suppose to do (I have trouble even downloading something with the size of 363KB using dial-up.)
Comment 10•21 years ago
|
||
Bug still there, 15alpha. Soon it may celebrate it's #1 birthday ;o)
Comment 11•21 years ago
|
||
*** Bug 182742 has been marked as a duplicate of this bug. ***
Comment 12•21 years ago
|
||
*** Bug 199745 has been marked as a duplicate of this bug. ***
Comment 13•21 years ago
|
||
I'm (still) getting this occasionally with 1.6. If I find a site that does it consistantly I'll try to do a sniff of the network stream to see if there is some particular thing that happens. (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113)
Comment 14•21 years ago
|
||
OK I did a successful Ethereal capture of a download that "reliably" drops out (I'm on dialup) yet download manager shows "Finished" and gives the completed file size (769KB of 769KB). The url is http://www.buzzys.net/dlexpert099.exe - it may or may not fail for you. It failed regardless of directly clicking on the link or doing a right-click save-as. Anyway, the short of it is that the other end simply closes the connection midstream (incoming TCP FIN/PSH/ACK with data, which my end happily replies to with it's own FIN/ACK usual closing sequence). This is the exact same sequence you get when the file is actually finished, the only difference, being the # of bytes received in total (obviously). I think because the connection is gracefully closed, and there is no timeout or other "error", Mozilla assumes the download finished properly. It would seem it doesn't "notice" that it didn't get as many bytes as it was expecting. The server HTTP response to our GET gave the correct filesize so we have no excuse there. Also, if I try to get the file again, Mozilla "knows" it didn't get all the file and happily HTTP resumes it where it left off! (the partial download must remain in cache - it resumes even if I delete the partial file from the destination folder). I think we simply need to always check the filesize received against what we were expecting when the connection closes. I won't attach the capture it as it's 800k zipped, please email me if you would like the files. (If we were really tricky we could attempt to automatically resume where it left off, but I think that's a separate bug already ;-)
Comment 15•20 years ago
|
||
*** Bug 236693 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 16•20 years ago
|
||
This also happens in Gentoo Linux with Firefox 1.0 pr. I have noticed it not with download manager, but with downloading many images at one time in different tabs. Some images do not complete, and others do. If I right click on the tab and select reload, the image continues to download from where it left off. I also see this behavior with one web page that has multiple images in it, although more rarely. When I reload the web page, it continues loading the images that didn't finish loading the first time.
Comment 17•19 years ago
|
||
I added the following to bug 182183 but this looks more appropriate - not clear whether that bug is a dupe of this or not... Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.5) Gecko/20041217 I was about to report this bug for Mozilla 175, while downloading Mozilla177 it was interrupted - download manager shows "11744KB of 11744KB" but if you look at the actual file only 2.5M was downloaded. I have seen this numerous times where it reports an interrupted download as complete. I suspect it may be related to using a proxy - I'm running Junkbuster on the local machine, but it clearly knows the expected file size and should know that its not complete. I've seen other cases where, because the client->proxy connection is not the one that failed, the client is unaware the end to end connection failed. AIR it either didn't occur or occurred much less w/o a proxy.
Comment 18•19 years ago
|
||
*** Bug 236456 has been marked as a duplicate of this bug. ***
Updated•17 years ago
|
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Comment 19•16 years ago
|
||
Still present in Firefox 3.0
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•