Closed Bug 1047940 Opened 12 years ago Closed 10 years ago

Disk cache doesn't get stored until restart if the cache directory gets deleted on runtime

Categories

(Core :: Networking: Cache, defect)

32 Branch
x86_64
Linux
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: sworddragon2, Assigned: michal)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release) Build ID: 20140801100255 Steps to reproduce: 1. Open Firefox and go to any website with content in it (for example this bug report). 2. Go to the cache directory (in my case ~/.cache/mozilla) and delete it. 3. Reload the website. Actual results: Only a few subdirectories were created but the cache doesn't get stored anymore. Expected results: The cache should get stored.
Reproduced with 2014-08-04-03-02-05-mozilla-central-firefox-34.0a1.en-US.linux-x86_64. It works after restarting.
QA Whiteboard: [bugday-20140804]
Component: Untriaged → Networking: Cache
Product: Firefox → Core
Summary: Cache doesn't get stored anymore if the cache directory gets deleted on runtime → Disk cache doesn't get stored until restart if the cache directory gets deleted on runtime
We could catch a specific OS error here and try to recreate the dir structure. This is low-prio for me.
It's not clear to me from the report whether it was tested with the new cache or with the old cache. In any case, I don't think we should try to recover from such weird situation on the fly. What is a valid use case for deleting the application data outside the application while it is running?
> It's not clear to me from the report whether it was tested with the new cache or with the old cache. What are the differences between them? > What is a valid use case for deleting the application data outside the application while it is running? I'm assuming Firefox is following the XDG specifications that causes it to store its cache into ~/.cache. In this case it is not unlikely that the ~/.cache directory gets deleted for maintenance reasons (even without explicitly targeting Firefox).
(In reply to sworddragon2 from comment #4) > > It's not clear to me from the report whether it was tested with the new cache or with the old cache. > > What are the differences between them? It is a completely new implementation of the cache which is located in ~/.cache/mozilla/firefox/profile/cache2 whereas the old cache is located in ~/.cache/mozilla/firefox/profile/Cache. We're definitely not going to fix this in the old cache. I would expect that the new cache will handle this situation much better, but I never tested it.
I have checked this and I'm on cache2. On retesting this again with deleting ~/.cache/mozilla on runtime I'm seeing 2 behaviors: 1. On loading a new website ~/.cache/mozilla isn't created anymore. 2. On visiting a website that was already visited before deleting the cache on runtime the directory structure down to ~/.cache/mozilla/firefox/_profile_/cache2/doomed is recreated but nothing else is stored anymore.
I'll have a look at it once I have some time, but this has low priority.
Assignee: nobody → michal.novotny
Severity: normal → minor
this is not worth the regression risk of doing
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.