User-Agent: Arena 1.0 Build Identifier: Version 2007112812 (1.5.4) When a download is interrupted, sometimes the download manager reports it as "Completed in MM:SS (X.Y MB)" where X.Y is the size that the originating site reported, NOT the size of the actual downloaded file, so that it looks like the download was complete. I only noticed this after I downloaded a file that was 4.4MB long and the downloaded copy was only 300K. Luckily I had not cleared my download manager and was able to locate several other files where this had happened, but I'm sure that I have missed some. When I noticed this happening I copied the URL and downloaded it via wget, and if the download is interrupted wget will restart the download after the interruption and complete the download in a second pass. It is possible that my squid proxy server is confusing Camino, so it can not resume the download the way wget does, but it should at the very least display something like "Completed in MM:SS (U.V MB of X.Y MB expected)" in a distinctive color or with a warning icon so that the user knows that the download is incomplete. There is no specific location where this happens, it depends on the state of my DSL. Since this can cause the user to lose data without knowing that data loss has occurred until later, I am setting the severity to "Critical". Since Camino does not control whether the data is lost, simply reporting accurately the results of a download would be sufficient to resolve the problem. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. 2. 3. Default theme, OS X 10.4.11 Macbook Pro *and* OS X 10.3.9 Mac mini PPC.

Classifying mis-reported file size data loss is a stretch; adjusting severity. Whatever is causing the download to be reported as successfully completed (which, given that it happens with wget if I understanding your description correctly, seems pretty clearly to be something other than Camino) has the serious bug. We can certainly change the download manager to always report the file size, but I doubt very much that we could report discrepancies as errors without having a lot of false positives. If the server (or proxy) is reporting that the download completed successfully, I think we need to trust it. Confirming for reporting the actual downloaded file size.

Ah, the underlying problem actually appears to be bug 237623, so apparently core does need to be trying harder to figure out if the download is really successfully downloaded. There are comments there from people who know a lot more about the networking code than I that agree with my feeling that just checking against the expected size and considering a mismatch to be a failure is probably not correct. I'm assuming that Chris didn't intentionally promote this back to critical without explanation, so fixing.

(In reply to comment #2) > I'm assuming that Chris didn't intentionally promote this back to critical > without explanation, so fixing. Yeah, that's Bugzilla not properly resetting the form attributes when I reload the page after a midair.

This bug would have caused data loss in at least three occasions where I was downloading snapshots and the transfer was interrupted, if I hadn't noticed the large discrepancy and looked for more cases. I am pretty sure that this is causing real data loss for people who are not aware of the possibility. I believe that this should be treated as critically as anything else that can invisibly corrupt a download. Clarification: wget does not report the transfer as being successfully completed, it reports it as being interrupted and restarts it (continues it if the server supports continuation).

You are welcome to make an argument in bug 237623 that that should be considered a dataloss bug, since that bug is about reporting interrupted downloads as successful, which I see as the "this" of "this is causing real data loss". The part of this that has been confirmed as a Camino bug is the file size, not the failure/success status, and we aren't going to treat that as dataloss.

Dup of bug 237623?

See comments 1/2/5; the initial report is partially a dup of 237623 and partially a legitimate Camino bug, and we're tracking the latter with this.

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]