Bugzilla

From digging down through the IO code, I think the most likely cause of this is a windows [`ERROR_SHARING_VIOLATION`](https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-#ERROR_SHARING_VIOLATION)  error.
(It could be an `ERROR_LOCK_VIOLATION`, but that'd involve someone explicitly locking a file, which seems unlikely).

`ERROR_SHARING_VIOLATION` just means the file is already in use (and was opened without sharing flags, which seems reasonable - you don't want other people fiddling with your mbox while you're writing to it). The description is "The process cannot access the file because it is being used by another process", but I suspect it'd also have to apply to other attempts to open the file from the same process.

Assuming no other app is opening the file (there's nothing we can do about that), this does sound awfully like it could be related to outputstream caching inside the mbox nsIMsgPluggableStore. On windows, if the outputstream was being kept open, any attempt to `.remove()` it would likely fail.

Bug 1777454 landed some changes which fixed a whole lot of cases where files were kept open after use. If the root cause of this bug is the same, those changes might have fixed this one too. The Quarantining aspect tallies too - over on bug 1777454, the quarantining flag had a big effect on whether or not the outputstream was being closed or not, and it seems to be similar here. See comment #33.

SO.

Looks like that patch was uplifted a few days ago, for 102.0.3. Has anyone managed to replicate it on that?
(see bug 1777454 comment 54)