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

RESOLVED EXPIRED

Status

Core Graveyard
File Handling
--
trivial
RESOLVED EXPIRED
15 years ago
a year ago

People

(Reporter: Markku Haikala, Assigned: Bill Law)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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

15 years ago
Were you downloading the files simultanously?
Did you have more than 1048 MB available in your tmp directory at the time?
(Reporter)

Comment 2

15 years ago
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

15 years ago
-> 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

15 years ago
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?
(Reporter)

Comment 5

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

Comment 6

15 years ago
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

15 years ago
-> file handling.

ftp just delivers the data, cache is just the final resting place.
Assignee: dougt → law
Component: Networking: FTP → File Handling
QA Contact: benc → petersen
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

15 years ago
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".
(Reporter)

Comment 10

15 years ago
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 
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.
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/
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.