182008 - Downloading stops when files in cache(?) exceed 1GB

Status: RESOLVED EXPIRED

(Core Graveyard :: File Handling, defect)

Description

[Markku Haikala]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

I was downloading 5 large files size about 200-380MB. All files downloaded only
partially and when I studied files I noticed that their counted size was 1048MB.
It was too exact size so I'm wondering is there some forgotten limit with files
downloading at the same time.

Reproducible: Didn't try

Steps to Reproduce:
1.
2.
3.

Actual Results:  
-

Expected Results:  
Download all the files

I'm really not sure is this a bug or something. Like 32MB HD limit with MS-DOS
3.3 or 640Kb RAM memory in DOS.

Comment 1

[R.K.Aa.]

Were you downloading the files simultanously?
Did you have more than 1048 MB available in your tmp directory at the time?

Comment 2

[Markku Haikala]

I was downloading those files simultaneously. I have 512K ADSL so I left my PC 
to do the job at nighttime. All files was modified at the same moment (1.17AM) 
so I first thought that maybe my ISP has some maintanance break. My available 
HD space is 12GB and my Mozilla settings are default. I have admin rights with 
my Win2k so there isn't any user limits.

Comment 3

[benc]

-> file handling.

Is your temp space on a smaller parition? Some download activity uses temp
space, and if that is a smaller parition, it creates a bottleneck.

Comment 4

[R.K.Aa.]

one question... you wrote you "first thought your ISP had a maintainance break":
Does that mean you were still online, and had been online all the time as far as
you can tell?

Comment 5

[Markku Haikala]

Temp space is in same partition.
I was online -no need to do login in SSG (service selection gateway/ISP login).

Comment 6

[Torben]

May be related to bug 184452, there seems to be a 2GB limit. 
Mozilla also seems to save to both temp and cache at the same time (bug 55307,
bug 132280, bug 138117 and maybe more), so the 1GB download might have reached
this 2GB limit.

Comment 7

[benc]

-> file handling.

ftp just delivers the data, cache is just the final resting place.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Actually, there could be all sorts of issues in necko here... are there any 
error messages?  Does this happen if a single file larger than 1GB is 
downloaded?

Comment 9

[benc]

Markku is talking about several files that total 1G.

If we are assuming that cache is the limit, what cache value is the bottleneck?
Is there a total cache size?

Gordon and I talked about the wisdom of using cache for downloading, and we
don't think it makes any sense. I'll create any relevant cache bugs separately
and note them here, but I think the best advice to download coders is "don't use
disk cache".

Comment 10

[Markku Haikala]

It was HTTP downloading.. So maybe files were two places at time and total 
files downloading size was 2GB. I was reading about other bug (55307) Torben 
mentioned and there was somebody mentioning doing test downloading with HTTP 
and FTP and with HTTP file was temp and cache dir at same time.

suggested direct DL to user destination dir using temporary filename sounds 
simple way to avoid unnecessary? file handling (temp/cache).

-just a ordinary user thought 

Comment 11

[Boris Zbarsky [:bzbarsky]]

Sending it directly to destination would avoid the temp file, but not cache, 
unless the HTTP apis get changed some (bug 55307).  Regardless, what you're 
seeing should not be happening; just changing the name of the file being 
written to will do nothing to affect this bug.

Comment 12

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 13

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.