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. :)

Duping to a later bug which has more info. *** This bug has been marked as a duplicate of 237623 ***