Download manager shouldn't place data in disk cache

RESOLVED DUPLICATE of bug 836445

Status

()

Toolkit
Downloads API
RESOLVED DUPLICATE of bug 836445
9 years ago
5 years ago

People

(Reporter: Dolske, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
While testing file downloads on WinCE, I noticed that files were being added to the disk cache (both when clicking a .zip file, and when selecting Save Link As). This sucks because when saving large files you blow out your disk cache for something that's not going to be used again.

Comment 1

9 years ago
I see this in FF 3.5.3 in XP.  This does seem like a bad thing; the file is being saved to its destination anyway, and many files won't even fit in cache (not without ignoring the max cache size, anyway).  It shouldn't even do this for smaller files--if I download a few hundred two meg files (a common use case with DTA), it could still stomp over my entire cache.  Cache for interactive browsing shouldn't have to compete with background downloads.

(There's bug 443067, too--it might be that this is actually handled more intelligently than it seems, but gets broken by the other bug.)

Comment 2

7 years ago
Should be fixed with bug 55307. Could you please retest? If it works now, please resolve this bug as dupe of that bug.

Comment 3

7 years ago
I retested this earlier today and FF4rc1 seemed to behave better, FWIW.
Paolo, do you know if the new Downloads API rewrite will address this issue? Or perhaps it has already been addressed, as comment #3 alludes to?
Flags: needinfo?(paolo.mozmail)

Comment 5

5 years ago
(In reply to Jared Wein [:jaws] from comment #4)
> Paolo, do you know if the new Downloads API rewrite will address this issue?
> Or perhaps it has already been addressed, as comment #3 alludes to?

In the current architecture there are several code paths that handle downloads,
and the caching behavior may vary. One of the goals of the new architecture is
to unify these code paths, thus we'll be able to control caching better.

In fact, when discussing the network cache rewrite, we determined that storing
partial requests in the cache is a non-goal, because the downloads code already
handles this using ".part" files.

There is bug 836445 already filed for the new API, we can use that to track the
work to be done.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(paolo.mozmail)
Resolution: --- → DUPLICATE
Duplicate of bug: 836445
You need to log in before you can comment on or make changes to this bug.