Closed
Bug 20088
Opened 25 years ago
Closed 24 years ago
Device Full on Download.
Categories
(SeaMonkey :: UI Design, defect, P2)
Tracking
(Not tracked)
People
(Reporter: jelwell, Assigned: law)
References
()
Details
(Keywords: crash)
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...
Updated•25 years ago
|
Assignee: dougt → law
Component: Silent Download → XPApps
Comment 1•25 years ago
|
||
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.
Updated•25 years ago
|
QA Contact: gbush → don
Comment 3•25 years ago
|
||
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+.
Reporter | ||
Comment 6•25 years ago
|
||
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.
Whiteboard: [PDT-]
Target Milestone: M13 → M15
Updated•24 years ago
|
Target Milestone: M16 → M17
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
*** This bug has been marked as a duplicate of 50697 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Comment 12•24 years ago
|
||
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"
Comment 13•24 years ago
|
||
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
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•