Closed Bug 182008 Opened 22 years ago Closed 19 years ago

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

Categories

(Core Graveyard :: File Handling, defect)

x86
Windows 2000
defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: markku, Assigned: law)

Details

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.
Were you downloading the files simultanously? Did you have more than 1048 MB available in your tmp directory at the time?
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.
-> 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.
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?
Temp space is in same partition. I was online -no need to do login in SSG (service selection gateway/ISP login).
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.
-> 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?
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".
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
Closed: 19 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.