531700 - Download manager shouldn't place data in disk cache

Status: RESOLVED DUPLICATE of bug 836445

(Toolkit :: Downloads API, defect)

Description

[Justin Dolske [:Dolske]]

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

[Glenn Maynard]

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

[OstGote!]

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

[Glenn Maynard]

I retested this earlier today and FF4rc1 seemed to behave better, FWIW.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

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?

Comment 5

[:Paolo Amadini]

(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.