Open
Bug 65770
Opened 24 years ago
Updated 1 year ago
File Download not recognizing disk full [before downloading, on dismissing file picker]
Categories
(Firefox :: File Handling, defect, P3)
Tracking
()
NEW
People
(Reporter: donguana, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: dataloss, helpwanted)
Downloading a file will not give notification when disk gets full. It will simply continue as if nothing happens and then it will truncate the file after the download has been completed. It is duplicated easily by downloading a file that is too big to fit in you cache. (Last test was done with the nightly build from Jan 17/2001) Would it not be better to simply save files that are not big enough to fit in cache directly to the location chosen in the "Save File" dialog box instead of placing it in the cache before moving it to the final its destination? This uses a lot of disk I/O for nothing, especially when dealing with large download files.
Comment 1•24 years ago
|
||
I just downloaded a 1.7M file onto a 3 1/2" floppy disk, what happened was that Mozilla completely downloaded the file and when completed, the file disappeared, no trace of it. No error boxes appeared to notify that there was no disk space. Shouldn't Mozilla check the disk space *before* the file begins to download? Changing status to NEW. Adding keyword dataloss. Adding myself to CC. OS: Win2k SP1 Moz Build: 2001011704 Win32 Talkback User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010117
Comment 2•24 years ago
|
||
over to the shiny new Networking: File Component.
Assignee: asa → dougt
Component: Browser-General → Networking: File
QA Contact: doronr → tever
Comment 4•24 years ago
|
||
This bug also occurs on linux with the latest build (2001031208) It silently fills the /tmp partition, and then copies whatever it got into the file name given. It is particularly annoying that it is silent.
This sound particularly annoying, Bill, if this sounds like backend, please feel free to reassign as appropriate. If you do reassign, please reset priority and target milestone and bump the nsbeta1+ down to an nsbeta1. Marking nsbeta1+, p1, mozilla0.9
I'm not getting to this dialog till next round...
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 7•24 years ago
|
||
This is working for me. I took a floppy disk that had about 275K available space on it and attempted to download a 300K file. It downloaded and then near the end popped up a window saying insufficient space. So I guess something got fixed since this bug was reported.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Comment 8•24 years ago
|
||
I take that back. Although I got the disk-full dialog, the file (or at least part of it) actually got downloaded. So I got a partial file which of course is garbage and it filled up my disk. Symptoms have changed slightly from what was reported, but it's still a bug. Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 9•24 years ago
|
||
I just compared this to 4.x behavior. In the 4.x case a message is displayed before the download even starts saying that there is insufficient space and asking if you want to continue. If you say no, nothing is downloaded. If you say yes, the partial file gets downloaded, just as in the current case. So maybe it's not a bug to download the partial file, although it would have been nice to warn the user before the download starts, as is done in 4.x.
Comment 10•24 years ago
|
||
netscape4's dialog is very nice, because it turns out that netscape4 didn't predict mountpoints in windows, so while my f:\ drive doesn't have space for huge files, f:\program files\dev does. The result is i'm warned about a possible disk full situation (before it starts downloading) and can tell it to go ahead because i know better. part of our problem is that we download to the temporary folder first. While we are doing that, if we run out of disk space, we should prompt the user with a dialog asking if we should delete the file. Currently our resume support isn't that good, but in the future, someone might really want to move it to another location and resume.
Comment 12•24 years ago
|
||
What would be nice, is a function to skip the cache for large downloads. (perhaps a checkbox "skip cache" on the "save as" dialogue?)
Comment 15•24 years ago
|
||
God, I hate these bugs. There are a couple of problems here, some real easy, some real hard. The easy one is that the OnDataAvailable code in nsExternalHelperAppService.cpp doesn't check for errors. If you download via File->SaveAs (or right-click on the link and "Save Link As") then you get error alerts (but the file isn't erased). There's a more general bug about cleaning up on errors, though, so I'll ignore that here. The first hard thing is that we have to propagate the error from nsExternalHelperAppService to the UI. There's code to handle that in the *other* download progress dialog, but not the one used here. The harder problem is that the way this code works, you can run out of space where the "temporary" download resides, *or* on the final destination drive. So these error situations get tricky to communicate to the user. Worse, if they run out of space on the temp location, they're pretty much SOL because they can't choose somewhere else (easily; it requires resetting some environment variables, shutting down, and restarting). I think we should add some error checking and put up a generic enough alert so that the user knows *something* went wrong. The bigger issue regarding the temp location business is addressed by bug 55690.
Whiteboard: 5/11, 2 days → time:2days
Comment 16•24 years ago
|
||
nav triage: thanks for the analysis bill. we'll move this to the nice-to-have pile for rtm, but not an rtm stopper at this time. i.e. m0.9.3 not m0.9.2.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 17•24 years ago
|
||
nav triage team: Sounds too complicated to take for mozilla0.9.3, marking mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
Keywords: nsenterprise
Comment 18•23 years ago
|
||
-> xp apps + qa
Component: Networking: File → XP Apps
QA Contact: tever → sairuh
Keywords: nsenterprise
Comment 20•23 years ago
|
||
Slightly modifying summary to distinguish from bug 27609.
Summary: File Download not recognizing disk full. → File Download not recognizing disk full [before downloading]
Whiteboard: time:2days
Target Milestone: mozilla1.0 → mozilla0.9.8
Updated•23 years ago
|
Summary: File Download not recognizing disk full [before downloading] → File Download not recognizing disk full [before downloading, on dismissing file picker]
Comment 25•23 years ago
|
||
This can't be fixed too easily until we figure out how to handle the issue covered by bug 55690 (because it gets too complicated to have to check for required space in two places, and worse, try to tell the user when the temporary location isn't big enough).
Depends on: 55690
Comment 26•23 years ago
|
||
Moving out to follow blocker bug 55690.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 27•23 years ago
|
||
Setting target milestone to milestone after target for blocker bug 55690.
Target Milestone: --- → mozilla1.0
Comment 28•23 years ago
|
||
Spam: Setting target milestone for all these to Future. Please note that most, if not all, will be fixed in the course of the work I'm doing for bug 27609. That fact is noted in the "depends on" field for each of these bugs (I think; go ahead and remedy that if you like). I just don't have time to deal with the wrath that comes with having too many bugs.
Target Milestone: mozilla1.0 → Future
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 30•22 years ago
|
||
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
Comment 31•22 years ago
|
||
pkw, interested in trying this? It's not always possible since the content-length is not always known (especially with streaming compression), but we could at least try to do better than we do now....
Updated•20 years ago
|
Keywords: helpwanted
Updated•20 years ago
|
Flags: blocking1.8a6? → blocking1.8a6-
Comment 38•20 years ago
|
||
Same thing if you save attachments from Mailnews/Thunderbird for example on a floppy disk or any other media.
Updated•15 years ago
|
Assignee: law → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → file-handling
Comment 44•14 years ago
|
||
OSX 10.6.7 Intel w/ ff 4.0.1 If a file is being downloaded and the disk runs out of space, there the download bar becomes unresponsive. (can not pause or cancel the download) "Show in Finder" is also greyed out. The file deletes its self, but the actual date in the .part file remains. Upon restarting ff, the .part file is deleted, the downloads are stopped (can see it happening while it start up, must be some sort of check) & there are empty files that are created with the file name of the original download. In contrast to the Stephen P. Morse's report where there were warning in 4.x, I have experienced no such warnings. My 2 cents at better behaviour. 1. If not enough disk space remains, warn (count disc space of other unfinished downloads to prevent 5 500mb downloads from appearing like it only takes 500m instead of 2.5g. Sometimes I see that files sometimes "reserve" the space and the .part file takes up the full space from the beginning. Personally, I like checking the size of the download to check for incomplete transfers. 2. Warning if after starting to download there will not be enough disk space to complete the transfer. Included in the warning should be the disk space needed to complete the transfer. (so the user has an idea how many downloads to cancel or how much room to clear from the computer) 3. Automatic stopping of the download upon disk being full. Allow controls to be responsive. 4. Error message saying that the disk has run out of space. 5. No deleting data without consent.
Updated•8 years ago
|
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Comment 46•5 years ago
|
||
With Firefox 71.0 I encountered the problem, that FF tries to save downloaded files (or files saved directly, e.g. Save-Image-As via right-mouse-click and then "v"), and does NOT mention, when the disk has become full durcing some save-actions.
Comment 47•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: critical → --
You need to log in
before you can comment on or make changes to this bug.
Description
•