搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

Learn More

How can .msf file be properly rebuilt, when deleting it while TBird not running, then running TBird, doesn't work?

  • 3 回覆
  • 1 有這個問題
  • 18 次檢視
  • 最近回覆由 Matt

more options

I'm presently running Thunderbird 45.4.0 on Linux.

After a crash, I discovered that a folder was considered to have many-many fewer messages than it should.

I searched the Inet for answers, found suggestions that if I quit Thunderbird, removed just the .msf file for the specific folder, then ran Thunderbird, it should build a new .msf file.

Thunderbird does build a .msf for the folder, but the majority of messages actually in the single ASCII file containing all the messages, are still not shown on the GUI and the count shown is many-many less than the number should be. I have manually verified that the messages are still physically in the single ASCII file representing the folder. So it seems that the .msf is not being properly rebuilt. Yet Thunderbird doesn't put any error messages on the screen.

Is there some separate utility I could use to rebuild the .msf file? The file command identifies .msf files as SGML. Is there perhaps a simple description of the format of a .msf file? At least then I could write a program myself to rebuild the .msf file.

I'm presently running Thunderbird 45.4.0 on Linux. After a crash, I discovered that a folder was considered to have many-many fewer messages than it should. I searched the Inet for answers, found suggestions that if I quit Thunderbird, removed just the .msf file for the specific folder, then ran Thunderbird, it should build a new .msf file. Thunderbird does build a .msf for the folder, but the majority of messages actually in the single ASCII file containing all the messages, are still not shown on the GUI and the count shown is many-many less than the number should be. I have manually verified that the messages are still physically in the single ASCII file representing the folder. So it seems that the .msf is not being properly rebuilt. Yet Thunderbird doesn't put any error messages on the screen. Is there some separate utility I could use to rebuild the .msf file? The file command identifies .msf files as SGML. Is there perhaps a simple description of the format of a .msf file? At least then I could write a program myself to rebuild the .msf file.

所有回覆 (3)

more options

I think an easier first step might be to open the mbox file itself in a good text editor (or use awk or sed) and replace the relevant X-Mozilla-Status flag value fields. See this thread:

https://support.mozilla.org/en-US/questions/1074528

Mailbox files (message stores) use a variant of the "mbox" file format and these are documented in various places on the web. Msf files appear to use mork which is less well known and seems prone to corruption. I think searching for mork (and discounting all the references to the Robin Williams character) will throw up some interesting insights into the foibles of this file type.

There is probably a formal definition on mdn but I haven't researched it myself.

由 Zenos 於 修改

more options

Zenos,

Thanks for your reply.

I used a simple awk program to give all the "X-Mozilla-Status" headers, values of "0001", placing the result into a new file in the same directory; diff'd the two to make sure the result was correct.

When I restarted Thunderbird, it evaluated the new folder, and effectively seemed to consider the content to be identical to the original; same number of messages, many-many messages missing from the summary view that it created, yet all the messages physically in the file.

Since I'm not familiar with the meaning of the status values, I should probably point out that, some of the messages don't have any "X-Mozilla-Status" header, and relative to the article you referenced, the folder is not the Inbox, is not accessed from the server via IMAP, nor is it on the server at all; messages are put in the folder via E-Mail filters.

I found some information on the Mozilla status headers, and I'm thinking about trying to add headers to those messages that don't have them, as well as changing the "...Status2" header values, to avoid having to use the information I found on the Mork format. I'm also wondering if perhaps there's something disrupted in the format of the mbox related file itself; I'm thinking about writing some code to audit that.

more options

my guess is r file is actually corrupt. Most likely in the blank line between messages. A message starts with a FROM line and ends in a blank. The only truly blank line allowed in the file. so scroll through where the disconnect appears in the file and the MSF list and look for something out of place. like a from with no blank line