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)

Product:
SeaMonkey
Component:
Download & File Handling
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
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).
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...
QA Contact: sairuh → petersen
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".
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
*** Bug 182609 has been marked as a duplicate of this bug. ***
*** Bug 180275 has been marked as a duplicate of this bug. ***
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
*** Bug 174916 has been marked as a duplicate of this bug. ***
same problem with 1.3 on win2k.

the window should at least give the amount that was transferred.  ie, 34000KB of
48000KB.
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.)
Bug still there, 15alpha. Soon it may celebrate it's #1 birthday ;o)
*** Bug 182742 has been marked as a duplicate of this bug. ***
*** Bug 199745 has been marked as a duplicate of this bug. ***
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)

 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 ;-)

*** Bug 236693 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
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.
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.
*** Bug 236456 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Blocks: 182183
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Still present in Firefox 3.0
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.