There's a public report that the directory includes:

• profile_count_(HASH).json
• uninstall_ping_(HASH)_(UUID).json
• UpdateLock-(HASH)
• cache2.(timestamp).purge.bg-rm-cachePurge-(HASH)

I can also confirm those files are all in my Windows machines too. The profile/uninstall things are from toolkit/mozapps/update/UpdateServiceStub.jsm, UpdateLock is from toolkit/xre/nsUpdateSyncManager.cpp, and cache2 files are from netwerk/cache2/CachePurgeLock.cpp.

The former two files are seemingly expected to be there per the docs, but the latter two files shouldn't be and are created by use of MultiInstanceLock which is added by bug 1553982.

Hi Molly, since you added MultiInstanceLock, do you have any idea why it's not being removed? Thanks!

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=740fad344989d083fad880469a0555ac68010d34&tochange=3f29a100ee068bd1396863ff58be989140badd3d

Suspect: Bug 1732435

This rather looks like the equivalent of Bug 1722777: these are just the remnants of a temporary profile directory. We worked pretty hard to eliminate this issue, so I'm surprised it's returned, but here we are.

I'm very surprised that Bug 1732435 impacts this. Alice0775, does that ticket make this reliable? Or does it just change an existing intermittent frequency?

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

This rather looks like the equivalent of Bug 1722777: these are just the remnants of a temporary profile directory.

I don't think that that is correct. I believe that that bug is talking about things being left behind in AppData, whereas this is talking about things in ProgramData.

I'm very surprised that Bug 1732435 impacts this. Alice0775, does that ticket make this reliable? Or does it just change an existing intermittent frequency?

I suspect that Bug 1732435 impacted this only insofar as that, prior to that work, Firefox would have saved these files in ProgramData/Mozilla instead of ProgramData/Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38. There is no reason that that bug would have caused those files to exist or not exist. It simply moved them.

(In reply to Kagami [:saschanaz] from comment #0)

The former two files are seemingly expected to be there per the docs, but the latter two files shouldn't be and are created by use of MultiInstanceLock which is added by bug 1553982.

What makes you think that the latter two files shouldn't be there?

Also, the title of this bug says that the files "are not being removed", but the description doesn't really mention what you mean by this. I just tried installing and running a new copy of Firefox, at which point I can see that an UpdateLock file is created for that instance. And when I uninstall Firefox, it seems to be removed. Is it not removed for you? Or is there some other point at which you are expecting that the file ought to be removed?

The UpdateLock files are intended and expected to be removed during application shutdown. If that's consistently not happening (*), it would be good to know why. That said, these files are all 0 bytes, so this is for the most part a purely aesthetic problem.

(*) on Windows; it's known to be unreliable at best on other OS's.

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

I'm very surprised that Bug 1732435 impacts this. Alice0775, does that ticket make this reliable? Or does it just change an existing intermittent frequency?

always. These files are never removed.

Oh. There was an intentional change to this behavior in bug 1696772, which I completely forgot about. So actually I was completely wrong earlier; we expect these files to hang around until the application is uninstalled.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #4)

I suspect that Bug 1732435 impacted this only insofar as that, prior to that work, Firefox would have saved these files in ProgramData/Mozilla instead of ProgramData/Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38. There is no reason that that bug would have caused those files to exist or not exist. It simply moved them.

Yup, that matches what I see in my machine. The first UpdateLock file in ProgramData/Mozilla/ started to appear in 2021-04-16 and it simply moved to ProgramData/Mozilla-(UUID)/ after 2021-12-10.

What makes you think that the latter two files shouldn't be there?

Just because I see no reason for it to be kept? Unless there actually are some good reasons. I admit I just guessed. (Edit: Oh, Molly says it's expected to be kept!)

Also, the title of this bug says that the files "are not being removed", but the description doesn't really mention what you mean by this. I just tried installing and running a new copy of Firefox, at which point I can see that an UpdateLock file is created for that instance. And when I uninstall Firefox, it seems to be removed. Is it not removed for you? Or is there some other point at which you are expecting that the file ought to be removed?

I think the expectation from the report is that the list of files shouldn't be infinitely increasing regardless of uninstall. I'll try clarifying.

(In reply to Kagami [:saschanaz] from comment #8)

I think the expectation from the report is that the list of files shouldn't be infinitely increasing regardless of uninstall. I'll try clarifying.

As far as I can tell, the list of files is not infinitely increasing. profile_count_(HASH).json, uninstall_ping_(HASH)_(UUID).json, and UpdateLock-(HASH) are all created no more than once per installation.

I can't speak to cache2.(timestamp).purge.bg-rm-cachePurge-(HASH). I don't have any of those in my directory and that code isn't owned by this team.

But I'm going to say that the bug as reported, that we use ProgramData to store files that we don't remove until uninstall time, is not a bug. We do that intentionally, and I don't see any problem with it.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #9)

As far as I can tell, the list of files is not infinitely increasing. profile_count_(HASH).json, uninstall_ping_(HASH)_(UUID).json, and UpdateLock-(HASH) are all created no more than once per installation.

No, I have 1,214 + 1,021 = 2,235 files in those ProgramData/Mozilla-* directories and it keeps increasing ☹️. (Only with those profile/uninstall/update files, because I don't use cache purger on my main profile.)

Oh. That's different then. You have a huge number of all of those files? Or just of some of them?

profile_count_ and UpdateLock- proliferates very quick, but uninstall_ping one is less frequent (but still many of them).

Running builds from mozregression creates UpdateLock too, so I wonder this also affects portable build users.

If you are running mozregression much, that probably explains everything. Mozregression uses dynamically generated, randomized install path names, so every single Firefox launch that Mozregression initiates is treated as a new installation that gets its own copy of these files. And mozregression never runs the uninstaller, so these would never get cleaned up.

If you want to clear out the 4 types of files you mentioned, you can try to see if you can reproduce this problem without mozregression. If you can, be sure to let us know and I'll look further into it. But, for now, I'm going to assume that this is essentially a problem of mozregression not cleaning up after itself and move this bug to that component.

(In reply to Kagami [:saschanaz] from comment #13)

I wonder this also affects portable build users.

We don't technically support a portable configuration at the moment. Bug 1752975 tracks potentially supporting such a thing. I'll add a note to that bug that we should consider these issues when/if we work on portable support.

Oh, good sleuthing -- I thought, "UpdateLock-$HASH shouldn't be changing frequently" but hadn't yet dug into why that might be so. So I'm glad to discover it's "just" mozregression. I wonder if we shouldn't start popping things into $UpdRootD/$InstallHash/... or similar to make this more obvious and easier to clean up...

(In reply to Nick Alexander :nalexander [he/him] from comment #15)

I wonder if we shouldn't start popping things into $UpdRootD/$InstallHash/... or similar to make this more obvious and easier to clean up...

I think that we had a reason for not doing this. IIRC we wanted to make sure that they weren't removed when a user updates via paveover install, which deletes parts of the update directory.

If you are running mozregression much, that probably explains everything

I run it seldomly and the files appear nearly every day, so unfortunately I don't think that's the case.

Edit: I run MSIX builds, can that be relevant here? 🤔

(In reply to Kagami [:saschanaz] from comment #17)

If you are running mozregression much, that probably explains everything

I run it seldomly and the files appear nearly every day, so unfortunately I don't think that's the case.

Edit: I run MSIX builds, can that be relevant here? 🤔

Oh. Maybe! Can you take a look at the "Application Binary" row in about:support and see what it says for your MSIX build? There have been some issues with them getting virtualized paths to their binaries. If those aren't stable, that would result in the hash changing so that different filenames would be used every time.

(In reply to Kagami [:saschanaz] from comment #17)

If you are running mozregression much, that probably explains everything

I run it seldomly and the files appear nearly every day, so unfortunately I don't think that's the case.

Edit: I run MSIX builds, can that be relevant here? 🤔

Oh, yes -- that actually makes some sense. Different versions get different installed paths; it's a little complicated. I think we probably need to standardize the installation hash based on the package family name (which doesn't include the version directly).

I've spun out https://bugzilla.mozilla.org/show_bug.cgi?id=1818606 to investigate and hopefully address this.

This bug is going to a different direction while the original report was more focused on cachePurge files, so I just spun out another bug: bug 1818714.