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)

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.
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
could this bug and bug 115210 be dependent on bug 31519, perchance?
ignore comment #2 --i meant bug 115207, not this one.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.9
nsbeta1+ per Nav triage team
Keywords: nsbeta1nsbeta1+
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).
That is in fact exactly what happened.
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).
-> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Whiteboard: [adt1]
ADT2 per ADT triage.
Whiteboard: [adt1] → [adt2]
-> blake
Assignee: ben → blaker
Status: ASSIGNED → NEW
This is not specific to download manager, and thus doesn't belong to me. -> default owner
Assignee: blaker → law
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?
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.
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
v
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.