Closed Bug 220874 Opened 21 years ago Closed 11 years ago

download manager fails

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: allltaken, Unassigned)

References

(
URL
)

Details

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
Whiteboard: DUPEME
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 ?
Flags: needinfo?(jrt)
No. Sorry for the slow reply.
Flags: needinfo?(jrt)
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
Closed: 11 years ago
Resolution: --- → WORKSFORME
Whiteboard: DUPEME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.