Closed Bug 20088 Opened 25 years ago Closed 24 years ago

Device Full on Download.

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Platform:
Other
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 50697

People

(Reporter: jelwell, Assigned: law)

References

(
URL
)

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...
Assignee: dougt → law
Component: Silent Download → XPApps
Reassigning to the unknown type download component owner.
Status: NEW → ASSIGNED
Target Milestone: M12
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.
QA Contact: gbush → don
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+.
Whiteboard: [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.
Whiteboard: [PDT-]
Target Milestone: M13 → M15
Not required for beta 1.
Move to M16 for now ...
Target Milestone: M15 → M16
Target Milestone: M16 → M17
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
Closed: 24 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
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.