Make sure that folder compaction temp files are obvious, and can't get picked up as new local folders.
Categories
(MailNews Core :: General, task)
Tracking
(Not tracked)
People
(Reporter: benc, Unassigned)
References
Details
Bug 1924918 installs a shutdown handler which cleans up temporary files if the app is shut down during folder compaction.
However, it doesn't help when we get an abrupt power-off or something.
Those files are going to be left in place, and because of the way local folder discovery works, may appear as new folders.
Also, with big mbox files, we could be back to the problem of Bug 1878541.
Currently, we use SafeOutputStream for writing new mbox files, and that doesn't give us any control over the filename, so the temp version of INBOX will be INBOX-1, which has no way for the user to identify that that file was left over from compaction.
We can't stop abrupt power-downs from leaving detritus from compaction, but we can make it more obvious to the user (and potentially an automatic clean-up routine) that such files are, in fact, detritus.
So to recap, we want any left-over folder-compaction temp files:
- to not be picked up as new local folders
- to be obviously left over (to users and/or an automated cleanup routine)
|
||
Comment 1•1 month ago
|
||
Like bug 333264?
However, it doesn't help when we get an abrupt power-off or something.
Like a crash.
|
Reporter | |
Comment 2•1 month ago
|
||
Note to self: make sure nsMsgLocalStoreUtils::nsShouldIgnoreFile() et al are updated too.
|
|
Reporter | |
Comment 3•1 month ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #1)
Like bug 333264?
Similar issue, but not quite... we have to be in the same folder (or at least be 100% sure we're on the same filesystem) as the file we're aiming to replace, so we can do an atomic(ish) rename to install the new file.
Suspect 333264 might be obsolete - looks like they gave up on using a separate dir for compaction at some point.
Description
•