Closed
Bug 115201
Opened 23 years ago
Closed 23 years ago
no error dlg displayed when target save location lacks space
Categories
(Core Graveyard :: File Handling, defect, P1)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
WORKSFORME
mozilla1.0
People
(Reporter: bugzilla, Assigned: law)
References
()
Details
(Whiteboard: [adt2])
sibling to bug 115197...
found using 2001.12.13.16 comm bits on winNT.
1. go to http://hopey.mcom.com/tests/
2. bring up a context menu over any of the links to large files and select Save
Link As
3. attempt to save the file to a volume that doesn't have enough disk space, eg,
a nearly-full floppy disk.
result: download progress briefly appears then goes away. this kinda implies
that the file is saved. so, i check the target directory and noticed that the
file was not saved.
Reporter | ||
Comment 1•23 years ago
|
||
also a problem on linux [2001.12.13.14 comm].
slightly different recipe, but the same idea:
1. make sure you have a partition with very little space to spare --eg, just
repeat step 2 [give different filenames for each round] below till you get
99-100% space in use.
2. go to http://jrgm.mcom.com/large-file-download/ and click the 95.4M file to
save it in a partition with little or no space available.
results: the download progress dlg will appear to save the entire file [get 100%
complete] --but when you look at the directory, the last saved file is
incomplete in size. eg,
195520 -rw-r--r-- 1 halo users 100000000 Dec 13 22:22 100000001.blob
195520 -rw-r--r-- 1 halo users 100000000 Dec 13 22:23 100000002.blob
195520 -rw-r--r-- 1 halo users 100000000 Dec 13 22:24 100000003.blob
2912 -rw-r--r-- 1 halo users 1482752 Dec 13 22:26 100000004.blob
notice how 100000004.blob is much smaller than it should be.
Severity: normal → major
OS: Windows NT → All
Hardware: PC → All
Reporter | ||
Comment 2•23 years ago
|
||
could this bug and bug 115210 be dependent on bug 31519, perchance?
Reporter | ||
Comment 3•23 years ago
|
||
ignore comment #2 --i meant bug 115207, not this one.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9
Comment 5•23 years ago
|
||
Using build 2002020406 on Window 2000
I don't if this is the same problem or not. Please confirm.
I download a huge file in a network directory. The download take place normaly,
but at the end, the file isn't there and I have no error message. If I try to
copy a file of the same size from another directory (with windows), I got a not
enought free disk space error.
What puzzle me is that I see the download bar progress up to the end. Is it
possible that the file was first save to a temporary directory, then mozilla try
(and fail to copy to the directory I choose).
Comment 6•23 years ago
|
||
That is in fact exactly what happened.
Comment 7•23 years ago
|
||
I don't know if that's already obvious to everybody, but if the file is already
present on the disk, I think that the error dialog should tell that the given
partition lack of space, but also offer to move the file on another partion.
Is that the way you already plan to solve the bug, or you consider just a error
message saying "Your file isn't saved" would be able to solve this bug. (In
which, offering a other saving location should go into a RFE).
Updated•23 years ago
|
Whiteboard: [adt1]
Comment 11•23 years ago
|
||
This is not specific to download manager, and thus doesn't belong to me. ->
default owner
Assignee: blaker → law
Assignee | ||
Comment 12•23 years ago
|
||
It seems nobody has tested this out subsequent to the 02/20/2002 checkin of my
fixes for bug 27609 which theoretically produced error alerts for most file
save failures.
Sarah, can you run through this test again, please? I'm going to try it myself.
There are known issues with errors that result when saving from the temp
directory to the final destination (sometimes, if not usually, no error alert
appears when that happens). I have another bug specific to that, though, so
maybe this one is fixed?
Reporter | ||
Comment 13•23 years ago
|
||
i tried saving a large file from my test site (eg,
http://hopey.mcom.com/tests/mozilla-source.tar.gz, via "save link target as"
from context menu) using today's branch commercial bits on a couple of platforms.
results
-------
* using win2k branch bits, 2002.05.01.08-1.0.0: works now, got a dlg saying
there isn't enough room. the regular progress dlg still remained up (meter
blank, but "cancel" button had turned into "close"), however --really minor.
* using mac 10.1.4 branch bits 2002.05.01.05-1.0.0: does NOT work. the meter
painted completely, but the final percentage was 8% (cancel button turned to
close as well). there was no error dlg displayed. and 2.8M (of the 35M file) was
downloaded.
Reporter | ||
Comment 14•23 years ago
|
||
scratch that --i had a different (older) build running on my mac at the time
--i've retested, *really* using 2002.05.01.05-1.0.0 bits. and it works fine! in
fact, i don't even get the lingering progress dlg that i saw on win2k.
okay, gonna mark this wfm. sorry about the earlier confusion.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•