Closed Bug 1343816 Opened 7 years ago Closed 7 years ago

CacheFileIOManager::CloseHandleInternal() can remove file belonging to other handle

Categories

(Core :: Networking: Cache, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox54 --- wontfix
firefox55 --- fixed

People

(Reporter: CuveeHsu, Assigned: michal)

References

Details

(Whiteboard: [necko-active])

Attachments

(1 file)

Per bug 1338675 comment 14, if we doom a cache file and open the same file before mMetadataWritesTimer fires, the cache file will be accidentally doomed.

We have a test patch on bug 1338675 comment 13.
It happens if the first handle is invalid, not doomed. If we doom the handle, we rename the file, move file to doomed directory and mFile points to a correct file.
Assignee: nobody → michal.novotny
Blocks: 1338675
Summary: Prevent metadata writes timer accidentally dooming cache file → CacheFileIOManager::CloseHandleInternal() can remove file belonging to other handle
Whiteboard: [necko-next] → [necko-active]
Attached patch fixSplinter Review
Attachment #8844887 - Flags: review?(honzab.moz)
Attachment #8844887 - Flags: review?(honzab.moz) → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cfe024d13c32
CacheFileIOManager::CloseHandleInternal() can remove file belonging to other handle. r=mayhemer
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/cfe024d13c32
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Should we consider fixing this in beta?
Flags: needinfo?(michal.novotny)
Probably not, it shouldn't happen too often and the cache should be able to handle situations when a file that is expected to exist isn't found on the disk.
Flags: needinfo?(michal.novotny)
Mark 54 won't fix as this is late for Beta54.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: