There's a public report that the directory gets cache2.(timestamp).purge.bg-rm-cachePurge-(HASH) files when shutting Firefox down:

1. Open Firefox Settings (about:preferences) page.
2. Click on “Privacy & Security” section in left-side pane.
3. In right-side pane, scroll down to History section and enable “Clear history when Firefox closes” option.
   PS: The same clear history when Firefox closes option can be enabled using about:config page. Just set privacy.sanitize.sanitizeOnShutdown preference/flag to True.
4. Again click on “Settings” button given next to the clear history option and enable “Cache” option only as shown in following screenshot:

After enabling the option, I closed Firefox and I checked the “C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38” folder again. I was surprised to see a new file “Cache2.2023-xx.purge.bg_rm-cachePurge-308046B0AF4A39CB” created in the folder. The file size was 0 bytes and Windows was unable to detect its file type. Windows was showing it as an unknown “.bg_rm-cachePurge-308046B0AF4A39CB file” as the extension was automatically taken from the file name.

That should be being created by CachePurgeLock calling MultiInstanceLock.

The similar UpdateLock- has a removal logic, maybe the cache purger needs an equivalent?

Hi Valentin,

Could you take a look? Thanks.

Regression investigation results:
Bug 1774840 - Implement new GC instructions in baseline (Part 3). r=rhunt.
Adds wasm baseline implementation and test cases for array.new_fixed.
Differential Revision: https://phabricator.services.mozilla.com/D154230

I think this is actually regressed by bug 1786256.

Backed out changeset 7c343aa2fe80 (Bug 1818714) for causing marionette failures CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=fB8U1UuASSWgUmpOx6RLoQ.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=7c343aa2fe804d52faeb3f768c54fd8c759277ca

Log: https://treeherder.mozilla.org/logviewer?job_id=414132194&repo=autoland&lineNumber=17221

Backout: https://hg.mozilla.org/integration/autoland/rev/bb590227d9cf55888cb2da104e0e8f88e4ced3e7

It seems the test broke because it found a very old lock file.
I added a task that cleans up older locks before checking that newer locks also get removed. I'll push it again after a clean try run.

https://hg.mozilla.org/mozilla-central/rev/f99ee8082b68