214328 - Download Manager fails to report some download errors

Status: RESOLVED DUPLICATE of bug 237623

(SeaMonkey :: Download & File Handling, defect)

Description

[Urban A. Haas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030726
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030726

Sometimes download manager states that a download completed 100%, even though
only a partial transfer occured before the download was interrupted. This
results in the temporarily downloaded file clobbering the existing file.

I regularily keep copies of PDF files on my hard drive from IBM. From time to
time, these PDF are updated and replaced with newer versions. When the updates
are posted, I download the newer versions. Sometimes the download doesn't
complete, but Mozilla indicates that it was successful and progress goes to
Finished and 100%. When this happens, I can see it instanteously jump from 37%
to 100% (numbers may vary). I usually download many files at once, sometimes the
files are still listed in the download manager from a previous successful download. 

I searched many download bugs, and there are similarities with bugs that had
disk space full and bad error messages being returned. However, I am not having
capacity issues, just issues with the download (or network) thread not passing
the correct error return code to the download manager, and as a result, since
there was no "error" with the download, the temporary file than overwrites the
file on the hard drive and I don't know I had an error until weeks later when I
attempt to open the PDF. I have had this happen downloading nightlies as well
from mozilla.org

Win2000 SP4, 384MB RAM, P3 ~1Ghz. In my scenerio, I'm not working with a 100%
stable LAN all the time. I'm using a WiFi (802.11b) gateway with built-in
NAT-based firewall, this is connected to a cable modem. So, from time to time
the connection pauses, then continues. This isn't really relevant, due to the
fact this same problem can result on a stable wired 100Mb Ethernet and SDSL, but
with much less frequency. I really don't think this is an issue with the LAN,
only that the frequency can exserbate the problem. I mention the stability of
the LAN only because sometimes TCP sockets do not survive. Other applications
see this, and behave correctly, Mozilla seems to think the transfer
completed.The LAN stability doesn't appear to affect other applications return
codes with similiar download capability (if the socket fails, the transfer fails
or is marked incomplete). 

Due to the fact that the return code is false, there is also no chance of
resuming a download.

This could be an issue with multiple downloads running where some do complete
correctly (started prior and after) and some do not and the wrong return code
from the wrong handle is returned.



Reproducible: Sometimes

Steps to Reproduce:
1. Have an existing downloaded file on your hard drive.
2. Have a multiple downloads of the same file (> 2 MB recommended). It may be
necessary to have many downloads happening simultaneously.
3. Have the socket fail.
4. The partial file is copied from $TEMP (%TEMP%, wherever) to the origional
file resulting in a corrupted image.

Actual Results:  
I get a corrupted file sometimes.

Expected Results:  
Should have stated that the download failed.

This seems similiar to bug <a
href=http://bugzilla.mozilla.org/show_bug.cgi?id=95969>95969</a>, but here I'm
addressing the return code issue being misleading. It is NOT related to <a
href=http://bugzilla.mozilla.org/show_bug.cgi?id=69938>69938</a> or many of the
other scary download should work like this bugs.

The workaround is to redownload the file, which for me is broadband so less
painful. :)

Comment 1

[Wayne Woods]

Duping to a later bug which has more info.

*** This bug has been marked as a duplicate of 237623 ***