First saw this on 95.0b1.

STR (in my case):

1. Right-click on Inbox and choose Properties
2. Click Repair Folder

On one of my Inboxes, nothing happens and no repair action begins.

Error Console spits out:

06:56:04.032 Uncaught folderPane.js:3406
Exception { name: "NS_ERROR_FILE_IS_LOCKED", message: "Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsIFile.remove]", result: 2152857614, filename: "chrome://messenger/content/folderPane.js", lineNumber: 3406, columnNumber: 0, data: null, stack: "rebuildSummary@chrome://messenger/content/folderPane.js:3406:24\nRebuildSummaryInformation@chrome://messenger/content/folderProps.js:478:23\noncommand@chrome://messenger/content/folderProps.xhtml:1:1\neditFolder@chrome://messenger/content/folderPane.js:3435:12\noncommand@chrome://messenger/content/messenger.xhtml:1:23\n", location: XPCWrappedNative_NoHelper }

rebuildSummary chrome://messenger/content/folderPane.js:3406
RebuildSummaryInformation chrome://messenger/content/folderProps.js:478
oncommand chrome://messenger/content/folderProps.xhtml:1
editFolder chrome://messenger/content/folderPane.js:3435
oncommand chrome://messenger/content/messenger.xhtml:1

(Removed because it's a duplicate message of my home PC.)

Looks like this is working again using the 95.0b4 build.

Wanted to follow up here again. When I started using my work PC yesterday morning, it was still churning through a repair operation on my primary GMail account which has 48k+ emails in it. What I was observing at 9AM was that it had 3-4k message left to go but was crawling at a pace of downloading one or two messages every 10 seconds or so. Mem useage would always creep up to the point of needing to End Task throughout the day. When I left work at 4:45PM, it still had 755 messages left to go and downloading seemed to have slowed even more. I disabled power management so that it could run all day/night until I come back Monday morning.

Whatever TB was churning through, it made my machine hardly usable. It made me have to End Task on it not less than 10 times during the day and relaunch TB and try to not touch it. Meaning, using my phone to check and send emails.

My far more capable home PC is still churning through something though Status Bar shows me nothing but Task Manager shows a constant 16%+ CPU use by TB. It's been running for 3 days straight now.

Is there anything in this perf profile that holds a clue?

Here's another quick perf profile with the test build of 95.0b5 after a fresh warm launch. I think there's a relationship between this one and bug 1742590.

So this problem has gotten so bad that I cannot even use TB anymore and have to use my org's Webmail. Yesterday I went nuclear and removed and re-added my GMail accounts and left my machine running all night long to let TB do it's thing.

This morning I came in and mem use was at 5.5GB and it was only 1/2 done downloading 49k messages. I was forced to End Task on TB and restart which seems to have improved the situation but I presume it will just creep back up by the end of the day.

This all seems to be a byproduct of the fix from bug 1734847. Meaning, running a folder repair after that fix landed appears to cause, in some cases, the folder repair operation to never finish / complete and TB seems to be stuck in some kind of endless loop.

Probably nothing but wanted to post what Error Console shows just before the shutdown crash happens.

Thanks Arthur!
I didn't spot anything obviously incriminating in the pref profiles. My reading of them was that it was spending most of the time in net code - which is what you'd hope to see, for IMAP.

The question is why it's running for so ridiculously long. I wonder if it's got confused in some way, and is re-downloading the same message(s) over and over and over? (there was a bug a while back that would do that for messages with a particular bad formatting... but that was addressed, and in any case I think the extra download only occurred when checking for new mail, not continuously like this)
Turning on IMAP logging might shed some light... but there would be a lot of dredging through the log output to figure out what it's doing. let me know if you'd like to try, and I'll work up some specific instructions.

In the meantime, I'll have a play around with huge inboxes (50K+ messages) and see if I can get anything to fall over...

(In reply to Ben Campbell from comment #8)

The question is why it's running for so ridiculously long. I wonder if it's got confused in some way, and is re-downloading the same message(s) over and over and over?

It seems like it's stuck in some sort of loop, yes. In comment 3, I mention that status bar doesn't show any activity yet Task manager shows 50-60% activity. It's like TB didn't get the memo to stop repairing the folder on which a repair was run. Or it's hamsterwheeling.

(there was a bug a while back that would do that for messages with a particular bad formatting... but that was addressed, and in any case I think the extra download only occurred when checking for new mail, not continuously like this) Turning on IMAP logging might shed some light... but there would be a lot of dredging through the log output to figure out what it's doing. let me know if you'd like to try, and I'll work up some specific instructions.

Yes, I remember this bug. But if you want some IMAP logging, let me know how to do it and I'll give it a go. Here's a question. When a Repair Folder operation is started, is there a way to send a Repair Folder Stop command as well? If not, maybe there should be for instances like mine else this might go on eternally for a user if a repair task goes off the reservation and never comes back.

I've done some Folder Repair testing on a couple of my lesser used GMail accounts that don't have too many messages (5k-6k) and it seems the speed at which it downloads messages and headers has greatly improved with the test build of 96.0b1. Messages seem to be downloading at a rate of 4 messages per second. The real test will by my primary GMail account which has 49K+. I intend to run a repair before I leave work and leave my machine running all night to see how far along it gets in the morning.

In case it's got something different, here's a perf profile of 96.0b1.

(In reply to Arthur K. [He/Him] from comment #0)

First saw this on 95.0b1.

Has anyone seen this earlier than 95.0b1, which shipped (build 2) Nov 3? (95.0b1 merge happened on Nov 1)

https://mzl.la/3GxOeps is a list of bugs closed fixed during 95.0a1 for Backend, Database, Networking, Networking: IMAP

Same issue, had it for the last 4 beta versions every beta since 92. repair inbox does not work.

(In reply to Mark from comment #14)

Same issue, had it for the last 4 beta versions. repair inbox does not work.

Mark,

Are you by chance seeing CPU usage even after you've run a Folder Repair and TB completed all tasks? Meaning, you're not doing anything in TB but it's chewing up CPU cycles?

I'm getting "not responding" more often.

I was testing a folder repair using 97.0b1 but it didn't even launch the repair operation. Error console threw the below. Seems similar to Comment 0.

Uncaught folderPane.js:3401
Exception { name: "NS_ERROR_FILE_IS_LOCKED", message: "Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsIFile.remove]", result: 2152857614, filename: "chrome://messenger/content/folderPane.js", lineNumber: 3401, columnNumber: 0, data: null, stack: "rebuildSummary@chrome://messenger/content/folderPane.js:3401:24\nRebuildSummaryInformation@chrome://messenger/content/folderProps.js:479:23\noncommand@chrome://messenger/content/folderProps.xhtml:1:1\neditFolder@chrome://messenger/content/folderPane.js:3430:12\noncommand@chrome://messenger/content/messenger.xhtml:1:23\n", location: XPCWrappedNative_NoHelper }

Oddly, I shut down TB and tried again and the Folder Repair did launch.

Is there any update on this. I'm on 98.0b1 (64-bit) and it is still an issue.

So rather than waiting on a Dev to hit / replicate this issue (or bug 1742975 / bug 1742590) and continue not having a working TB install, I just backed up my current TB profile and nuked everything (TB, TB profile folders, etc.) and started over from scratch. My TB profile is 73.5GB in size and after 1 full day of TB re-downloading all my 3 GMail account emails, I am 100% back to a working state using 98.0b2 and 0% CPU use when idle.

So, my thought now is that at some point from probably TB 94 > TB 95, this unknown and underlying bug did screw up my profile but likely it's been fixed by post-94/95 TB beta versions. I say this with cautious optimism. I don't know that we'll ever know exactly what caused this but this solution worked for me 100%. I say this as a user whose profile was 13+ years old (with 23+ years of emails!) and hating to have to "start over" with a clean profile. But, it completely fixed it for me.

I am going to continue monitoring my Inbox and Spam folder as that's where I'd typically see message corruption. I hesitate to close this bug as WFM but whatever happened that caused the corruption in the first place must have been tied to an issue with the profile itself and it seems the only way out of this mire is to back up the profile (and server / IMAP info and related settings therein), delete all the old profile folders and start over from scratch. Just my 2 cents.

(In reply to Arthur K. [He/Him] from comment #19)

So, my thought now is that at some point from probably TB 94 > TB 95, this unknown and underlying bug did screw up my profile but likely it's been fixed by post-94/95 TB beta versions. I say this with cautious optimism. I don't know that we'll ever know exactly what caused this but this solution worked for me 100%. I say this as a user whose profile was 13+ years old (with 23+ years of emails!) and hating to have to "start over" with a clean profile. But, it completely fixed it for me.

I moved the IMAP folders in the affected account and moved them to an offline drive for safety then re-created the account as a POP account. Then, I deleted the .msf files from the safe-store and moved the folders back into the 'new' directory structure and I've been better.

For good or ill I'm happy I'm not the only one with this problem.

The majority of issues are now prominent whilst using my "spam" folder. Due to an over zealous spam filter set by ISP it tends to be a second inbox.

I'm still getting the merging messages, "not responding" alerts and cannot repair said folder.

TB is becoming unusable.

So is anyone still seeing this bug (compact fails)?

(In reply to Magnus Melin [:mkmelin] from comment #22)

So is anyone still seeing this bug (compact fails)?

Yes, using TB 100.b3, error generated right now

Uncaught
Exception { name: "NS_ERROR_FILE_IS_LOCKED", message: "Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsIFile.remove]", result: 2152857614, filename: "chrome://messenger/content/folderPane.js", lineNumber: 3419, columnNumber: 0, data: null, stack: "rebuildSummary@chrome://messenger/content/folderPane.js:3419:24\nRebuildSummaryInformation@chrome://messenger/content/folderProps.js:479:23\noncommand@chrome://messenger/content/folderProps.xhtml:1:1\neditFolder@chrome://messenger/content/folderPane.js:3448:12\noncommand@chrome://messenger/content/messenger.xhtml:1:23\n", location: XPCWrappedNative_NoHelper }
folderPane.js:3419

Yes. Thunderbird has created so many large nstmp files, my drive has run out of room!!!!!!!!!!!

(In reply to Worcester12345 from comment #24)

Yes. Thunderbird has created so many large nstmp files, my drive has run out of room!!!!!!!!!!!

I had this happening as well to a large degree. Perhaps not as bad as you as I had a 1TB drive with room to spare. But, ultimately, what I did in comment 19 fixed everything for me. YMMV.

Yes, repair folder still does not work.

(In reply to Mark from comment #26)

Yes, repair folder still does not work.

You should go in up above and vote for this bug, then. This is how the developers know who is having this problem.

(In reply to Worcester12345 from comment #27)

(In reply to Mark from comment #26)

Yes, repair folder still does not work.
You should go in up above and vote for this bug, then. This is how the developers know who is having this problem.

I was one of the original reporters and it still isn't working. Not sure why i'd need to upvote it...

(In reply to Mark from comment #28)

I was one of the original reporters and it still isn't working. Not sure why i'd need to upvote it...

Mark, this is not working for you on version 102? (just to be clear)

Fernando,
TCW,
Does it fail now with 102.0b7?

Hello, yes this still happens in TB 102.0b7 , the only difference is the line number in folderPane.js, now 3414

Uncaught
Exception { name: "NS_ERROR_FILE_IS_LOCKED", message: "Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsIFile.remove]", result: 2152857614, filename: "chrome://messenger/content/folderPane.js", lineNumber: 3414, columnNumber: 0, data: null, stack: "rebuildSummary@chrome://messenger/content/folderPane.js:3414:24\nRebuildSummaryInformation@chrome://messenger/content/folderProps.js:479:23\noncommand@chrome://messenger/content/folderProps.xhtml:1:1\neditFolder@chrome://messenger/content/folderPane.js:3443:12\noncommand@chrome://messenger/content/messenger.xhtml:1:23\n", location: XPCWrappedNative_NoHelper }
folderPane.js:3414

https://searchfox.org/comm-central/rev/7db3fb60ede28ef82c543940f39e67d7ff0ea7b9/mail/base/content/folderPane.js#3414

Are you on Windows?
Sounds like the file was not closed properly (at least on time). Does it make a difference if you set mailnews.downloadToTempFile true or false?

(In reply to Magnus Melin [:mkmelin] from comment #32)

Are you on Windows?

Yes, I'm using Windows 10.

Sounds like the file was not closed properly (at least on time). Does it make a difference if you set mailnews.downloadToTempFile true or false?
I did some tests.
My original config for mailnews.downloadToTempFile was TRUE.
I updated to FALSE, restarted TB an use the repair many times, and the operation worked as expected in every try, whiout any error on console.
Moved some email from one IMAP account to other and tried the Repair , it worked without any error.
Then I flipped the mailnews.downloadToTempFile to TRUE again, restarted TB and the error return when trying to repair a folder.

To be clear

Setting mailnews.downloadToTempFile to FALSE apparently solves the problem

(In reply to Wayne Mery (:wsmwk) from comment #30)

Fernando,
TCW,
Does it fail now with 102.0b7?

I bumped up to 102 RC2 today and tried to repro this and it doesn't repro for me.

Benc, do you have a potential patch?

(In reply to Fernando Hartmann from comment #31)

Hello, yes this still happens in TB 102.0b7 , the only difference is the line number in folderPane.js, now 3414

Uncaught
Exception { name: "NS_ERROR_FILE_IS_LOCKED", message: "Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsIFile.remove]", result: 2152857614, filename: "chrome://messenger/content/folderPane.js", lineNumber: 3414, columnNumber: 0, data: null, stack: "rebuildSummary@chrome://messenger/content/folderPane.js:3414:24\nRebuildSummaryInformation@chrome://messenger/content/folderProps.js:479:23\noncommand@chrome://messenger/content/folderProps.xhtml:1:1\neditFolder@chrome://messenger/content/folderPane.js:3443:12\noncommand@chrome://messenger/content/messenger.xhtml:1:23\n", location: XPCWrappedNative_NoHelper }
folderPane.js:3414

I am just curious.
Isn't there a way to show such an I/O error with a proper modal dialog to the user?
I mean this is a serious error in that we cannot remove a directory which we ought to have succeeded in removing it, and
the user is entitled to know this kind of error.

Maybe a symptom of forgetting to the check of return status from low-level I/O code (or thrown exception as in this case).
I am a bit worried that not many people look in the error console to figure it out and simply puzzled. This is bad. They may think TB does not work whatever the reason is and simply move off to other mail client (or webmail).

I mean average users of TB would say, "Error Console? What is that?". Why not present an important error as such to the user.

(In reply to Wayne Mery (:wsmwk) from comment #35)

Benc, do you have a potential patch?

No, but I'm looking into it now.

(In reply to ISHIKAWA, Chiaki from comment #36)

I am just curious.
Isn't there a way to show such an I/O error with a proper modal dialog to the user?

In generally, I'd agree in that the general UX principle should be: "if any operation a user explicitly initiates fails, an error message should be displayed somewhere they'll definitely see it". But really, that's way up in GUI territory, and not something I have any insight on. Something for a separate discussion maybe.
The failing nsIFile.remove(true) call is being done on the javascript side, so presumably the exception could be caught there and displayed to the user. But rebuildSummary() performs a lot of steps, and any of them could fail. So I think a more general error handler would be more appropriate.

I mean this is a serious error in that we cannot remove a directory which we ought to have succeeded in removing it, and
the user is entitled to know this kind of error.

It'll only be a directory if the user is on maildir. It's more likely to be an mbox file.

From digging down through the IO code, I think the most likely cause of this is a windows 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)

(In reply to Ben Campbell from comment #39)

...
Looks like that patch was uplifted a few days ago, for 102.0.3. Has anyone managed to replicate it on that?
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1777454#c54)

Using 104.0b3, I just tried it on my main work Inbox and it didn't have any issue afterward. I'm assuming here that the patch exists in 104.0b3.

Hooray! Sounds promising...

Yes, I think we have good news here.
I just tested many times the repair of my 3 accounts using TB 104.0b3 and the repair works perfectly every time.
No error was showed in error console !
I think its solved !
Congratulations to you guys !

Thanks for the feedback.

Someone name Na Na asked me (via email) if this still happens or if it work for me. it works fine now.