To reproduce: 1) Fill up /home 2) Make sure: 'df -h' Does it say 0 under Avail? Smile. :) 3) Download something. I was downloading this when it happened: ftp://iodynamics.com/pub/mirror/linux-jdk/JDK-1.1.7/i386/glibc/v3/jdk_1.1.7-v3-glibc-x86.tar.gz 4) Uh oh- pop up box: "Unknown topic: component://netscape/appshell/component/xfer;on Error Data: 2 80004005" 5) Click Ok. 6) Watch as the error message keeps coming back. Loop. You can't get out of this loop without killing Mozilla. This is bad... Although it's probably pretty bad if they're drive is full...
Assignee: dougt → law
Component: Silent Download → XPApps
Reassigning to the unknown type download component owner.
The error handling code does a nsIChannel::Cancel but this apparently is not doing what it's supposed to. I'll track this down and either get it fixed or put in some additional error handling to at least prevent the message box loop.
reassigning QA contact-per component page
Summary: Device Full on Download. → [DOGFOOD] Device Full on Download.
Target Milestone: M12 → M13
With Judson Valeski's latest (and greatest!) enhancements to netlib and the stream-xfer code, this problem is somewhat reduced in severity. The symptom now is that the download appears to complete when the output device is full (or we otherwise fail to write to it). Unfortunately, if the file being downloaded is too large then the code erroneously keeps on reading (even though it can't write) and sometimes this produces a hang (observed on WinNT in at least one reasonable scenario). We (valeski and me) will investigate further in order to fix the hang (at a minimum) or get the error conditions handled properly (which might be deferred till M13 or later since that's likely not a DOGFOOD situation). I'd like the PDT to take a look at this and assess whether the potential hang situation warrants flagging this as PDT+.
Putting on PDT- radar. Stress conditions are not part of dogfood.
when i had this bug happen i was also downloading with lynx. lynx was very friendly it just froze the download, and when I made space on the device, it continued download. This would be an ideal solution for mozilla. Rather than ceasing download and notifying that the device is full.
Priority: P3 → P2
Summary: [DOGFOOD] Device Full on Download. → Device Full on Download.
Target Milestone: M13 → M15
Not required for beta 1.
Move to M16 for now ...
Target Milestone: M15 → M16
Move to M20 target milestone.
Target Milestone: M17 → M21
currently 2000083111 linux comm bits crashes on file download when the device is full. This is worse! nominating for nsbeta3 to (at least) prevent the crash.
Keywords: crash, nsbeta3
*** This bug has been marked as a duplicate of 50697 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
But usually don't we keep the lower ID bug as the main bug? See also another dupe: bug 48620 "Didn't warn about file size"
Anyway... Verified dupe of bug 50697: "Solaris/Linux crash when saving file if over disk quota/out of disk space" now marked all platforms
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.