Shouldn't write to cache stream after cache entry has been marked truncated

VERIFIED FIXED in mozilla0.9

Status

()

Core
Networking: Cache
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Matthew Cline, Assigned: gordon)

Tracking

Trunk
mozilla0.9
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
If the file that you're downloading is larger than the disk cache you
have, then the cache will fill up and the cache entry for the file
will be marked as TRUNCATED_CONTENT in InterceptStreamListener::Read()
in mozilla/netwerk/cache/mgr/nsCachedNetData.cpp.  However, every
time the Read() method is called after that point in the download,
it will call the private write() method again, and it will fail again;
repeated failure can do weird things (see bug 44452).  So, once the
entry is marked truncated, we should never attempt to write to the
cache stream again for that cache entry.  I will attach a patch
which fixes this problem.
(Reporter)

Comment 1

18 years ago
Created attachment 11141 [details] [diff] [review]
Don't write to cache stream after cache entry has been marked truncated
(Reporter)

Comment 2

18 years ago
Accepting bug.
Status: NEW → ASSIGNED

Updated

18 years ago
Keywords: nsbeta3

Comment 3

18 years ago
Matthew did you intend to take this bug over? Its a minus otherwise. 
Whiteboard: [nsbeta3-]

Updated

18 years ago
Target Milestone: --- → Future

Updated

17 years ago
Assignee: neeti → gordon
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9

Comment 4

17 years ago
Cache bugs to Gordon

Comment 5

17 years ago
Cache bugs to Gordon

Comment 6

17 years ago
old cache bug, should be fixed in the new cache
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 7

17 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.