Closed Bug 129604 Opened 22 years ago Closed 22 years ago

when temp location is full, get confusing results when downloading

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: bugzilla, Assigned: law)

References

(Blocks 1 open bug)

Details

(Whiteboard: [adt2 rtm],custrtm- [vrfy'd on trunk on win2k] [ETA 06/24])

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...
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
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.
Keywords: qawanted
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?
Blocks: 129923
Depends on: 55690
nsbeta1+ per Nav triage team, Nav2
Keywords: nsbeta1nsbeta1+
Whiteboard: [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
Whiteboard: [Nav2] → [adt2]
Target Milestone: --- → mozilla1.0
Depends on: 129614
fixed
fixed, really
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Whiteboard: [adt2] → [adt2 rtm]
Whiteboard: [adt2 rtm] → [adt2 rtm],custrtm-
Keywords: adt1.0.1
Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.
Keywords: adt1.0.0
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!
Whiteboard: [adt2 rtm],custrtm- → [adt2 rtm],custrtm- [vrfy'd on trunk on mac/win2k]
Whiteboard: [adt2 rtm],custrtm- [vrfy'd on trunk on mac/win2k] → [adt2 rtm],custrtm- [vrfy'd on trunk on win2k]
marking as verified per Comment #16 From sairuh (se).
Status: RESOLVED → VERIFIED
Whiteboard: [adt2 rtm],custrtm- [vrfy'd on trunk on win2k] → [adt2 rtm],custrtm- [vrfy'd on trunk on win2k] [ETA 06/24]
Target Milestone: mozilla1.0 → mozilla1.0.1
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).
Keywords: adt1.0.1
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.