Thunderbird 38.1.0 lost message folders



Folder and Message Lists
3 years ago
20 days ago


(Reporter: lstout, Unassigned)


38 Branch

Firefox Tracking Flags

(Not tracked)



(2 attachments)

19.53 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
17.88 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document


3 years ago
Created attachment 8636929 [details]
2015-07-21 - Thunderbird 38.1.0 screen shot.docx

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

I allowed Thunderbird to upgrade to 38.1.0, and then I opened Thunderbird.

Actual results:

In the folder pane, the names of two of my subfolders were greyed out and italicized.  I was able to recover the messages from one, but the other now says it has zero messages (even though it occupies 26 MB).

Expected results:

All of my folders and subfolders should have been listed in normal typeface.  All of my messages should have been accessible.

Additional information:  For the subfolder that I recovered, I created a new subfolder in the same folder with a slightly different name, and moved all of the messages.  Then I deleted the input subfolder.

For the other subfolder, I renamed it.  After the rename, no messages were listed in this subfolder.

For the subfolder that I recovered, the name of the new subfolder was originally shown in normal type.  After I restarted Thunderbird, it showed as greyed out and italicized; but the messages remained accessible.

The subfolders that are having the problem are at the third level (userid/folder/subfolder/subfolder), and have fairly long names.  However, I have several other subfolders that are at the same level of nesting, and have equally long names, but do not have a problem (so far).

The case in which I have previously seen subfolder names greyed out and italicized is when I tried to create a new folder and made the mistake of including a slash in the folder name.  Then Thunderbird created the part before the slash as a normal folder name and the part after the slash as a greyed out and italicized subfolder.  However, the names of the subfolders in this problem do not contain slashes, and worked fine before Thunderbird 38.1.0.

Also note that although the screen shot shows that I have turned on the new feature of folder pane columns, this problem originated immediately upon bringing up Thunderbird 38.1.0, before I enabled folder pane columns.

The PC is running Windows 7 Professional, Service Pack 1.


3 years ago
Severity: normal → critical

Comment 1

3 years ago
Probably the same bug.
Thunderbird 38.1.0 lost messages several times now.
I just moved the mails from inbox to subfolders and afterwards they are gone.
"Nachrichten suchen" does not find them anymore.

They are still on the POP3 server so no damage up to now.

Comment 2

3 years ago
lstout - your folders are imap?

peter, this bug is about an inaccessible folder, not lost messages per se
Flags: needinfo?(lstout)


3 years ago
Whiteboard: [closeme 2015-08-15]

Comment 3

3 years ago
I have the same problem as lstout.  Any solution yet?

Comment 4

3 years ago
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #2)
> lstout - your folders are imap?
> peter, this bug is about an inaccessible folder, not lost messages per se

Yes, my folders are IMAP.

Your question caused me to think of trying to access the folders via
a Webmail client.  We have IPSWITCH IMail Server.  With this method,
the subfolders appear, both the names that I see under Thunderbird and
the names from before the rename and delete.  However, none of these
subfolders display any messages, not even the subfolder that has
messages accessible under Thunderbird.

Concerning your reply to petermaffter, it seems to me that the problem
involves both inaccessible subfolders and lost messages.
Flags: needinfo?(lstout)

Comment 5

3 years ago
Please update to version 38.2.0.
Is it better?
Flags: needinfo?(petermaffter)
Flags: needinfo?(lstout)

Comment 6

3 years ago
Resolved per whiteboard
Last Resolved: 3 years ago
Flags: needinfo?(petermaffter)
Flags: needinfo?(lstout)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2015-08-15]

Comment 7

3 years ago
Can't say I completely understand comment 4. It would be great to have more information. If the issue continues in version 38.2, we might want to check some nightly builds to determine when the problem starts.

Comment 8

2 years ago
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #5)

> Please update to version 38.2.0.
> Is it better?

Thunderbird updated itself to version 38.2.0 today.

If you mean:  Did the status of the subfolders involved in the problem improve?  Then the answer is No.  Both of the subfolders are still greyed out and italicized, and one of them still shows as having no messages.

My next step will be to have the folder restored again.  This will answer whether a freshly restored folder gets corrupted when Thunderbird 38.2.0 comes up.

Is this problem associated with any of the bugs listed as fixed in version 38.2.0 at
?  None of them appear (to me) to be related.


2 years ago
Ever confirmed: true
Resolution: INCOMPLETE → ---

Comment 9

2 years ago
The message folder was restored on the mail server.
After the restore, the subfolders showed the same problem as before.
We thought that Thunderbird and/or the mail server might be caching the folder information and not recognizing the restore.
I deleted the subfolders and then the folder, under Thunderbird, and then exited from Thunderbird and from Webmail.
The message folder was restored again on the mail server.
Now the restored folder does not show up at all, under either Thunderbird or Webmail.

Under Thunderbird, I went into File / Subscribe, but this folder did not show up as available to subscribe
I tried selecting the parent folder and doing Edit / Folder Properties / General Information / Repair Folder ; this had no effect.
My current guess is that because the restore was done externally, the mail server is not recognizing that the restore happened.
Possibly if the mail server were restarted, it would reread the actual directories and notice the restored folder; but that seems pretty drastic.

Later:  A colleague suggested deleting the file panacea.dat, which Thunderbird uses "to record all the email directories & subs for a given user.  Sometimes we find that changes made 'externally' to the Thunderbird email directories are not visible in the Thunderbird client because they are not known in Panacea.dat.  Bottom line is that we found that deleting (or renaming) the Panacea.dat for a given user causes Thunderbird to traverse the directories at startup, make a new Panacea.dat, and allows the externally-made changes to become visible in the Thunderbird client."

I renamed "C:\Users\lstout.IDP\AppData\Roaming\Thunderbird\Profiles\srqjro5b.default\panacea.dat" (while Thunderbird was down).
Sure enough, Thunderbird created a new panacea.dat file during startup.  Disappointingly, the restored folder still did not show up.

Comment 10

21 days ago
Did you sort this out?
Flags: needinfo?(lstout)
Whiteboard: [closeme 2018-01-15]

Comment 11

20 days ago
Created attachment 8938981 [details]
status as of 12/27/2017
Flags: needinfo?(lstout)

Comment 12

20 days ago
(In reply to Wayne Mery (:wsmwk) from comment #10)
> Did you sort this out?

No, the missing messages never came back.                            
At some point I changed the subfolders to be separate folders.  The attachment "status as of 12/27/2017" shows the current status.  The folder names now look normal, neither italicized nor grayed out.  The folder that lost the messages no longer occupies any bytes.          
I am currently on Thnderbird 52.5.2 (32-bit).

Comment 13

20 days ago
Thanks for the update. Without a protocol log or steps to reproduce it seems unlikely we could sort this out. So => incomplete.
Last Resolved: 3 years ago20 days ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2018-01-15]

Comment 14

20 days ago
Thank you for your attention to this problem.
You need to log in before you can comment on or make changes to this bug.