196996 - download runs out of disk space -> doesn't release the disk space until browser is quit

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Anthony Baxter]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030307 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030307 Phoenix/0.5

I was downloading a large file onto a filesystem which, as it turned out, 
wasn't large enough for the file. I came back to find a popup saying "out
of disk space blah blah". Clicked "ok", popup was dismissed. _However_,
the disk space of the partial download was not freed up. The file wasn't
visible in /tmp, which leads me to suspect that the browser still had an 
open file handle to the file. After I closed the browser, the disk space 
was immediately freed up.


Reproducible: Always

Steps to Reproduce:
1. Download a large file (larger than will fit on the filesystem you've chosen)
2. Wait for the "out of space" popup
3. Click 'ok', observe that the filesystem is still full (the partial download
is not discarded)

Actual Results:  
Filesystem stayed full

Expected Results:  
Freed up the disk space.

This is a recent CVS build of phoenix... Not sure on setting the priority -
I personally think it's a pretty major bug, but it's not exactly a common
one that you trip over.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a problem with Mozilla too, or just with Phoenix?

Comment 2

[Anthony Baxter]

No idea - I no longer have mozilla installed, just phoenix. I can try tomorrow
and see if I can get the same effect (although I might try making it use something
other than /tmp - filling the root filesystem isn't my idea of fun... :-/

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

as long as this was only tested on phoenix, moving outside of browser

Comment 4

[Simon Paquet [:sipaq]]

Anthony, can you please retest this with a current firebird and app suite
nightly build. I suspect that this also happens on the suite, but we need to
make sure.

Comment 5

[Yan Morin]

I try it on a mounted file (i didn't think about floppy lol)
However, this is what df tell me before:
[root@127 fsfile]# df
/tmp/fsfile               2803        13      2790   1%
/home/yansanmo/project/cvs/mozilla/yansanmo/test/fsfile

and after:
[root@127 fsfile]# df
/tmp/fsfile               2803      2801         2 100%
/home/yansanmo/project/cvs/mozilla/yansanmo/test/fsfile

and in the folder:
[root@127 fsfile]# ll
total 2800
-rw-------    1 yansanmo yansanmo        0 fév  3 19:12 abigfile.ogg
-rw-------    1 yansanmo yansanmo  2842624 fév  3 19:12 abigfile.ogg.part
drwx------    2 root     root        12288 fév  3 18:50 lost+found

Comment 6

[Yan Morin]

I found why!!!
in the file
http://lxr.mozilla.org/mozilla/source/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp#2229
we test for PERSIST_FLAGS_CLEANUP_ON_FAILURE to cleanup the file
but if you look at
http://lxr.mozilla.org/mozilla/search?string=CLEANUP_ON_FAILURE
this flag is never set on.

Not enough memory error happens in the nsWebBrowserPersist::OnDataAvailable method.
http://lxr.mozilla.org/mozilla/source/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp#739


You can find my investigation there: http://yansanmo.no-ip.org:8080/a/fbbug#196996

Comment 7

[Boris Zbarsky [:bzbarsky]]

1)  How are you downloading?  Not all downloads use the persistence object. In
particular, any download that would leave the "abigfile.ogg.part" file around
does NOT use the persistence object.

2)  Isn't it better to leave the partial download there rather than wipe it all
out?  I believe it is.  If we use "save link as", do we not leave the
so-far-donwloaded file there when we run out of disk space?

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

> http://yansanmo.no-ip.org:8080/a/fbbug#196996

unfortunately, I don't think any of the people working on this code can read
french...

> 2)  Isn't it better to leave the partial download there rather than wipe it
> all out?  I believe it is.

Maybe so, but we currently delete the file, at least those that go through
exthandler. (nsExternalAppHandler::OnStopRequest calls Cancel() if
NS_FAILED(aStatus), which deletes the temp file)

>  If we use "save link as", do we not leave the
> so-far-donwloaded file there when we run out of disk space?

that's a good question though. looking at this code briefly, I don't see where
we'd do that...

Comment 9

[Yan Morin]

After testing nsExternalAppHandler when my disk is full, it prompt me 
NS_ERROR_OUT_OF_MEMORY and not NS_ERROR_FILE_DISK_FULL error message.

NS_ERROR_OUT_OF_MEMORY say to Quit some applications
and
NS_ERROR_FILE_DISK_FULL say that your disk is empty.

So if I want to download, I have to free some space on my disk and not quit some
application.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, strange that you get that error code, but anyway... it shouldn't matter,
downloads that go through exthandler should delete the file when they fail

Comment 11

[Ali Ebrahim]

Can anyone reproduce this in either Mozilla 1.6 or Firefox 0.8 or newer? Seems
like it's probably a Browser bug, though no one has confirmed this yet.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Given how much of downloading firefox has forked, there better be damned good
evidence this is a browser bug...  Even if it's present in both, it may require
two separate patches to two different files to fix.

Comment 13

[Kevin Brosnan]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040329 Firefox/0.8.0+
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040327
Firefox/0.8.0+

Both are WFM

I downloaded a large .PDF file from adobe to a NTFS and a FAT 32 partition, I
will try an EXT partition if you want just email me. The out of disk space
message appeared. The result of this was the downloaded part of the file was
placed on the drive. The drive space was used up but the file was visible so
this is WFM on Windows XP SP 1 and Debian unstable 2.4.x kernel.

I have a vague recolection of a bug fix that changed the way FireFox or maybe
the Gecko core downloads files recently. Mozilla browsers use to download to
some temp dir they now store the partial file in the dir that you are
downloading to.

Comment 14

[Asa Dotzler [:asa]]

WFM per comment 13. Please reopen if you can reproduce with a build as new or
newer. Thanks.