found using 2002.03.06 commercial verif bits on linux rh7.2. spun off while verifying bug 27609. currently preparing to test on mac 10.1.3 and win2k --will add to this bug once i get results there. 1. to prepare for this, i filled up the temp location to near capacity --i just downloaded and made copies of the mozilla source for this. on linux, it's /tmp; on mac it's the Desktop; on win2k it's (afaik) C:\WINNT\Temp. 2. download a file which wouldn't fit in the temp location --i used the nightly mozilla source again, eg, ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-03-07-08-trunk/mozilla-source.tar.gz 3. in the file picker, selected a target location different from the temp location, then clicked "save" button. results: on linux, either after i click the link at step (2), or at step (3), i get an alert dlg saying, "Data connection: Connection reset by peer." after i dismiss it, i can eventually get to the file picker and chose a location and click "save". the progress dlg appear and seems to complete. however, when i check my target location, there's an incomplete version of the file.

i can repro this on mac 10.1.3 under the following circumstances: using a new profile && default temp location [set under Internet config] is the Desktop. strangely, with an existing profile on mac 10.1.3, this wasn't a problem --got the alert, "There is not enough room on the disk to save to [temp path]:[salted filename]. Remove unnecessary file from the disk and try again, or try saving to a different location." but i believe this because that existing profile was old enough to still have the browser.download.dir pref set to my previous temp location, which wasn't the Desktop. it was on the same partition as the Desktop, but located at Maggie:Carbon Downloads & Installers rather than Maggie:Users:sairuh:Desktop. still preparing win2k box to test this...

y'know, unless there's an easier way to test this, i'm wondering if this might be considered an edge case? in other words, how common is it for the temp location to get filled up and thus make this situation possible? i ask because it's taking an awful long time for me to fill up my temp locations on various machines... then again, this might be a case of *my* usage not being common. ;) anyhow, if this is an edge case, feel free to minus this.

Sarah, would you happen to know whether the temp location is filling up _before_ you get the filepicker up or after?

Boris: unfortunately, i cannot remember whether /tmp was filling up before or after the file picker appeared --sorry! i've already cleaned up my partitions, in order to do other testing/work (it gets really slow with little room) on those boxes. peter, paul et al.: if there are machines available with limited diskspace where i can test this issue more feasibly, do let me know. also was recently able to reproduce this on win2k. more info about the "Data connection: Connection reset by peer." error: i got it in win2k when i selected the "save to disk" radiobutton in the helper app dlg. iirc, if i cancelled downloading before i get to setp (3), the salted file remains in /tmp, even after quitting the app.

Yes, this is part of the agressive pre-caching by downloading to a temp location even before the save dialog is dismissed, in some cases. If there is room in temp, but not in the destination, you don't even get an error, it just fails silently.

Sarah: would it work to just create a small volume, and point the tmp environment variables to it?

se: fwiw unfortunately it's pretty easy to fill up temp and not notice. I had edit.com fail on me 90% of the time, the reason? my system drive was full so %temp% was full ... you could probably point $tmp to a floppy disk :-)

Can we consider fixing this and numerous other bugs related to this temp file <pre> saving, by just saving the file in response to the user's directions?

nsbeta1+ per Nav triage team, Nav2

*** Bug 131783 has been marked as a duplicate of this bug. ***

*** Bug 135613 has been marked as a duplicate of this bug. ***

converting nav2->adt2, ->1.0

fixed

fixed, really

Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.

i was able to verified this as fixed (using 2002.06.17.0x comm trunk bits) on win2k and mac 10.1.5. two cases: a. "save link target" from context menu. b. saving via helper app dlg (left-clicking a downloadable link). results: * on win2k, i had temp point to a small ramdisk i setup (then filled manually). for (a) and (b), i was able to download a large file with no problems (downloaded to the desktop). * on mac os x, i had temp point to a nearly-full zip disk. (a) passed with no problems (was able to download a large file to desktop). but, with (b), i got the "out of disk space" error. is this expected on Mac when downloading via the helper app dlg? if the Mac behavior is expected for (b), i'll go ahead and mark this verified. however, if someone would be able to get to verifying this on linux (on the trunk), that'd be great!

marking as verified per Comment #16 From sairuh (se).

was this fixed as part of another checkin. i don't see a patch here. removing adt1.0.1, please re-nominate (by adding back the adt1.0.1 keyword).