Open Bug 65770 Opened 24 years ago Updated 2 months ago

File Download not recognizing disk full [before downloading, on dismissing file picker]

Categories

(Firefox :: File Handling, defect, P3)

defect

Tracking

()

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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
over to the shiny new Networking: File Component.
Assignee: asa → dougt
Component: Browser-General → Networking: File
QA Contact: doronr → tever
Bill, care to look at this?
Assignee: dougt → law
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
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.9
I'm not getting to this dialog till next round...
Target Milestone: mozilla0.9 → mozilla0.9.1
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: 23 years ago
Resolution: --- → WORKSFORME
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 → ---
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.
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.
Whiteboard: 5/11, 2 days
*** Bug 56957 has been marked as a duplicate of this bug. ***
What would be nice, is a function to skip the cache for large downloads.
(perhaps a checkbox "skip cache" on the "save as" dialogue?)
Changed milestone and removed + so this bug can be re-prioritized.
Keywords: nsbeta1+nsbeta1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Keywords: nsbeta1nsbeta1+
nav triage: frequency is low enough to make this a P3. 
Priority: P1 → P3
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
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
nav triage team:

Sounds too complicated to take for mozilla0.9.3, marking mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
Keywords: nsenterprise
-> xp apps + qa
Component: Networking: File → XP Apps
QA Contact: tever → sairuh
Keywords: nsenterprise
spam: over to File Handling.
Component: XP Apps → File Handling
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
Summary: File Download not recognizing disk full [before downloading] → File Download not recognizing disk full [before downloading, on dismissing file picker]
*** Bug 82478 has been marked as a duplicate of this bug. ***
*** Bug 108716 has been marked as a duplicate of this bug. ***
*** Bug 110151 has been marked as a duplicate of this bug. ***
*** Bug 114347 has been marked as a duplicate of this bug. ***
OS: Windows NT → All
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
Moving out to follow blocker bug 55690.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.9 → ---
Setting target milestone to milestone after target for blocker bug 55690.
Target Milestone: --- → mozilla1.0
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
Blocks: 129923
*** Bug 138047 has been marked as a duplicate of this bug. ***
Blocks: 69938
QA Contact: sairuh → petersen
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
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....
*** Bug 211791 has been marked as a duplicate of this bug. ***
*** Bug 235938 has been marked as a duplicate of this bug. ***
*** Bug 259262 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
*** Bug 271058 has been marked as a duplicate of this bug. ***
*** Bug 259757 has been marked as a duplicate of this bug. ***
*** Bug 272184 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a6?
Flags: blocking1.8a6? → blocking1.8a6-
Same thing if you save attachments from Mailnews/Thunderbird for example on a
floppy disk or any other media.
*** Bug 187652 has been marked as a duplicate of this bug. ***
*** Bug 297349 has been marked as a duplicate of this bug. ***
Assignee: law → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → file-handling
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.
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified

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.

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 → --
Duplicate of this bug: 1834161

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(gijskruitbosch+bugs)
Severity: -- → S3
Flags: needinfo?(gijskruitbosch+bugs)
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.