95210 - Location of Temp file should be same as Download File Destination

Status: VERIFIED DUPLICATE of bug 55690

(SeaMonkey :: General, defect)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3+) Gecko/20010812

Location of Temp file should be same as Download File Destination

Reasons:

1. The temp folder is usually on C:\ and for WinNT this is often limited to 2
GB, where much of the space is already used up by other programs that insist on
using C: - I tried downloading a 150 MB file to my F: drive and after 4 hrs!!!
the download failed because C: had become too full :(

2. Partially downloaded files become lost in temp folder nirvana because most
users never look there. They do however usually know and use the folder THEY
have chosen as the destination folder. We should follow GetRight's lead in this,
as they are very experienced designing good download managers.

3. Again, following GetRight's lead, if the partially downloaded file has the
extension filename.ext.MOZ, then users (A) would know that the file was a
download file that was not finished yet. (B) could doubleclick the file to
resume the download; (C) the MOZ extension would have an accompanying icon that
further identifies it as belonging tio Mozilla. All thiss is most useful if the
partially downloaded file is where the user expects it to be, namely in the
destination directory he chose.
The main reason right now for me is "1." because I am really upset that the
partially downloaded file location is one I have no control over (without
changing my entire system configuration - which is often not possible in an
office environment). Additionally, implementing this has the added bonus of
making points 2 and 3 easier to implement in the (hopefully near) future.
BTW. Severity: Major, because it has caused dataloss and has wasted up to four
hours of PC-time for me.

Comment 1

[Peter Lairo]

oops, just checked: "loss of data" is Severity = Critical - changing severity to
critical.

Comment 2

[Warner Young]

If this isn't a dupe of bug 55690, it's certainly related.

Comment 3

[Matthias Versen [:Matti]]

This is a dupe !
Plairo: Please the read the bug before you possible disagree with this duping...

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

Comment 4

[Peter Lairo]

verifying dupe (if I'm allowed)

Matti: I *always* read the bugs that my bugs are duped against. Sometimes the
dupes are incorrect. Here, it is OK ;)