Disk cache size set in preferences is ignored

UNCONFIRMED
Unassigned

Status

()

P3
normal
UNCONFIRMED
15 years ago
a year ago

People

(Reporter: pgut001, Unassigned)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Firebird appears to ignore the disk cache size set in the preferences. 
Specifically, setting the "Use up to n KB of disk space for the cache" value
(confirmed by checking the "user_pref("browser.cache.disk.capacity", 0);" in
prefs.js) to a particular value (say 8MB) results in Firebird filling the
allowed 8MB, and then continuing to save further information to disk beyond this
limit (see "Steps to reproduce" for more information).


Reproducible: Always

Steps to Reproduce:
1.Create a fixed-size drive (e.g. an 8MB RAM drive) and point Firebird's cache
directory to the drive
2.Set the Firebird disk cache size to something less than the drive size, e.g. 6MB.
3.Browse (say) a graphics-heavy site that fills the cache.
Actual Results:  
The browser kept saving data to disk until the 8MB drive filled up (beyond the
set 6M limit), whereupon it sometimes deleted files and at other times just
stopped cacheing anything (it's a bit hard to determine, it varied over
different runs of the browser).  After continued use things seemed to converge
on all cacheing halting, with the disk full and no recycling of cached files. 
In addition trying to clear the cache had no effect, it simply moved the index
files to a Cache Trash directory without freeing up any space.  Since the disk
was still as full as before, cacheing still didn't work.

Expected Results:  
1. It should have stuck to the size limit specified for the disk cache.
2. It should have been able to detect a disk-full condition and handled it by
deleting the oldest entries in the cache rather than just failing.
3. Emptying the cache should really empty it (delete entries), not just move the
data elsewhere without freeing up any space.
(Reporter)

Comment 1

15 years ago
Sorry, the cut-and-pasted prefs.js entry above is currently set to 0 MB to turn
off cacheing until this problem is fixed.  In the original tests it really did
say 8 MB and not 0 MB :-).

Comment 2

15 years ago
WFM using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20031221
Firebird/0.7+

Please re-test with the latest nightly build to see if you can still reproduce
the problem.

Comment 3

15 years ago
confirming this. my cache is set to 50000kb, and currently my cache folder is:
61284kb.

Firebird 0.8.0+ (20040130) on XP

Updated

15 years ago
Assignee: firefox → darin
Component: Preferences → Networking: Cache
Product: Firefox → Browser
QA Contact: mconnor → core.networking.cache
Version: unspecified → Trunk
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/
(Reporter)

Comment 5

13 years ago
(In reply to comment #4)
> If you can still reproduce this problem in the latest version of the product 
> please visit the URL of this bug and add a comment to that effect, giving more
> reproduction information if you have it.

It's still present in the latest version of FireFox (1.07), my cache directory
is currently showing 10MB of data with an 8MB limit set.  Steps to reproduce are
exactly the same as when first reported nearly two years ago.
1.0.7 is the latest stable release, but it is based on a branch that is a year
and a half old now, please retest using the links provided.

Comment 7

12 years ago
-> default owner
Assignee: darin → nobody
(Reporter)

Comment 8

12 years ago
(In reply to comment #6)
> 1.0.7 is the latest stable release, but it is based on a branch that is a year
> and a half old now, please retest using the links provided.

Just to make sure this doesn't die out, the problem is still present in the latest version of Firefox, 1.5.0.4.
Disk cace settings seems to work for me with FF3.0.6
(Reporter)

Comment 10

10 years ago
I'm currently sitting here with FF 3.0.6 using 24MB out of a maximum of 16 MB disk cache, so the problem's still present.

Comment 11

4 years ago
Peter, still see this?
Flags: needinfo?(pgut001)
Whiteboard: [closeme 2014-10-10]
(Reporter)

Comment 12

4 years ago
Funny you should mention that, I was reading the release announcement for the new cache implementation and thought "I wonder if they've fixed this one yet?".  Checked disk usage, it was using ~50MB out of a total of 32MB.  The problem seems to be due to video streaming, the stream is cached until disk space is exhausted, no matter what the cache size is set to.  This is with Firefox's built-in video codec, no plugins (e.g. Flash) installed.
Flags: needinfo?(pgut001)

Updated

4 years ago
Whiteboard: [closeme 2014-10-10]
Whiteboard: [necko-backlog]
You need to log in before you can comment on or make changes to this bug.