User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916 I clicked on the links to download Sun Java J2RE version 1.42, and the download mgr started downloading the approximately 15Mb file. After downloading about 12Mb, I got the message that the file could not be saved because the source file could not be read. First of all, the download wasn't complete so it should not have stopped, timed out or whatever. Secondly, It's a very bad idea to download into the Windows\temp directory and then move the file to the requested place when done. The download ought to be stored right where the user requests. Thirdly, the download manager ought to know that the download was not complete and should NOT have been trying to treat it as done. Fourth, the download mgr should NOT delete the partial download because it's often possible to resume an interrupted/halted download. The download mgr ought to be able to do this like third-party downloaders such as Go!zilla do. Fifth, I went looking for a cut-and-pastable URL for the download and couldn't find any in either the browser or the download manager. How can I put that URL into Go!zilla to download the file right if I can't put the URL into the clipboard? Sixth, I have wasted a lot of time the past week or so trying to download large files and finding that they fail. The 60Mb of OpenOffice.org was one such file that repeatedly failed, possibly from a timeout though the download manager didn't give any useful error message. The download should be saved during the download with the name of the file, possibly with .par appended, and saved in the location specified. This would make the download resumable by a smarter download manager. Reproducible: Sometimes Steps to Reproduce: 1. Click a link to download a large file 2. Wait while the download progresses 3. Actual Results: The download halts with the message that the download could not be written to disk because the source file could not be read. The source file was evidently a file with another name stored in a temporary directory. Expected Results: Mozilla should have stored the partial download in the specified location, not a temporary location, and should have continued downloading until the entire file was fetched. If the download was halted by the server, the partial file should have been saved so the download could be resumed.
*** Bug 220873 has been marked as a duplicate of this bug. ***
> Secondly, It's a very bad idea This is covered by other bugs, with a great deal of discussion in them as to why it's done this way. But yes, it needs to be fixed. We seem to have a lot of reports of downloads failing recently, all on windows. Biesi, any idea what's up?
Assignee: blake → file.handling
Component: Download Manager → File Handling
On the message "file could not be saved because the source file could not be read", see bug 203689. On the issue of cut-and-paste urls, see bug 142798. On the issue of storing downloads in the temp directory, see bug 69938. On the issue of resumable downloads, see bug 18004.
I have no idea what's up. _Nobody_ responded to my request in bug 203689. The diff between compreg.dat.good and .bad showed nothing significant, afaict. But, I just looked at the code that sends kReadError... I noticed OnStopRequest does it, but SendStatusChange does not handle necko error codes specifically... maybe it is just "Connection reset by peer" or something, impossible to tell w/o the actual error code.
Are some sites lowering their timeout time in an attempt to screen out slower connections?
When did Microsoft's MSDUN 1.4 come out? It reports connection speed to the user as the maximum, typically 115,200 bps. If this figure is reported to the server and the server uses it to figure a timeout value, the false bps would result in a barely adequate and often-too-low timeout value for Windows users. (As you-all know, dialup rates may approach but don't exceed 56K bps.) Maybe Microsoft browsers have a workaround for this hypothetical problem which would affect Windows users.
Download is still failing in 1.7rc2. See: http://www.gpsinformation.org/joe/misc/moz17rc2downloaderror2.jpg for an example. This is a MAJOR MAJOR MAJOR problem. Seems like you could fix this. I have reported it in the past two editions.
upgrading to 1.8.3a downlaods have stopped working on my win2k box. No file now starts the download manager, whether from on-site or off site servers chris
I haven't noticed this problem for many months using current milestone releases of Mozilla. Since my last report (Oct 1, 2003) Mozilla starts a download in a temp location and moves the temp file to the specified location as soon and the user selects the name and location. Other bugs in this discussion are marked fixed too. I'm waiting until after the Nov election to resume testing as I don't want to risk any system problems now. The problem Chris just reported with 1.8.3a on Win2K sounds different from the failures I reported. Chris, were you trying html or ftp access of files? Is the registry set right by the installation to open a download? What changed since downloading worked?
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Some filetypes that are downloaded go through the dialogs including the selection of destination name and directory, and others don't. I've commented on this before in other downloading bugs, and the problem exists in Mozilla 1.7.12 for Windows. I'll just make a new bug report about it after checking it out on a Seamonkey nightly.
Assignee: file-handling → nobody
QA Contact: chrispetersen → file-handling
I think this is not anymore a problem.
Do you still see this issue ?
No. Sorry for the slow reply.
I should add that my primary OS now is Linux, not Windows. I can't comment on performance in Windows.
Thanks for your reply and I would expect that this works now,
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.