Build Id: > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090511 Shredder/3.0b3pre If "outdated msf condition" existed for a folder, and if "copy of mail to the folder" happened without explicit folder open, next exception was reported to Error Console upon mouse-over to the mail folder. This is phenomenon observed during test for Bug 492344. > Error: uncaught exception: [Exception... "Component returned failure code: 0x80550005 [nsIMsgFolder.msgDatabase]" nsresult: "0x80550005 (<unknown>)" > location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 1951" data: no] [ Test Scenario ] (0) Local "Test" folder has mail-1(unread), and compacted normaly. Terminate Thunderbird. (1) Edit file of "Test" by text editor, and add mail data for mail-2(unread). => File size of "Test" is increased. (2) Restart Thunderbird. mail count=1 is displayed for "Test" folder at folder pane. (3) Never touch "Test" folder, and copy unread mail-3 to "Test" folder from other mail folder. => Data of mail-3 is added to file of "Test". => Timestamp of "Test.msf" is not updated. => Open(write mode) of "Test.msf" is successful. i.e. "Test.msf" is not opened(in write mode) by Tb. => Mail count of "Test" folder is still 1. If step (3) is repeated, same phenomenon is observed. (4) Move cursor on "Test" folder at folder pane. => Above exception is issued in Error Console. If step (4) is repeated, same phenomenon is observed. It looks that "folder open" is not executed at step (3), or silently fails, and "internal rebuild-index due to outdated msf" is not invoked. Note: Same exception is reported to bug 410555 too. But line number is different, "when problem occurred" is still unclear except "when I moved a message to the trash", meaning of "Titles disappeared in Window" is still unclear.

The basic questions that I have with this class of bugs are 1) do we support "outdated msf condition" imposed externally for a folder, and if we do 2) what is the correct response to this. An alternate viewpoint is that we do not support externally caused "outdated msf condition", which would invalidate the basic premise of this bug. A related biewpoint is, even if we do support it, then "Error: uncaught exception" is the correct response, which invalidates the "problem" reported by this bug. Lest you misunderstand my perspective, I did an experimental patch a few months back that was designed to treat "outdated msf condition" as an acceptable non-error-producing condition for the database, with the premise being that database users in the program would query for the outdated condition only if they were in a position to do something about it, that is were prepared to do an async folder reparse. For all other uses, the outdated database would just be used without complaint. This would eliminate the class of errors that this bug is discussing completely. But others with whom I discussed this approach over IRC were unenthusiastic, so I did not pursue it. At the moment, it is standard practice to get the database in js without try blocks to catch an "outdated msf condition" error message. So I would claim that the error message that you saw is expected behavior. Since I put effort into eliminating this, obviously I am not completley comfortable with these errors. But at the same time, I don't think it is productive to try to find cases where you can produce this error message. If you don't like this behavior, I think it would be better to either file or choose a bug to represent this whole class of issues, and promote its solution.

so, yes, this is more or less expected behavior. Allowing invalid db's is not a good option, but a possible option is to kick off a async parse of the folder to generate the db, and then complete the commnand, as we do for compact and search.

(In reply to comment #1) > An alternate viewpoint is that we do not support externally caused "outdated msf condition" It's emulation of power failure/system crash etc. Read Bug 492344 comment #2, please. And, see bug 410555. This issue really occurred on the Earth. (I guess "corrupted msf " case.)

(In reply to comment #1) Before writing my comment. Kent James, please understand next; The "Error: uncaught exception" is first unusual phenomenon which is externally observed after restart of Tb around "outdated msf condition". It may affect on problems/phenomena after it. So I'm tryng to dig out real/root problems when the exeption occurs, in addition to asking "Error: uncaught exception" itself is due to flaw in code or not and why the exception occurs. I've probably understood what has happened. I guess next. 1. outdated msf condition exists 2. "folder open" is probably not called upon mail data appending (data from folder cache is used as for folder pane display after restart?) (mail's attributes are updated in memory?) 3. Upon mouse-over, .msf file is checked(at least timestam&file_size) and detects mismatch between data in memory and data for .msf file, or "no cached MsgDB" condition occurs, or something wrong is detected => The exception Note-1: If auto-compact is invoked after above 2(and 3 in test for Bug 492344), phenomenon of Bug 492344 can occur currently. Note-2: If Tb 2, "deleted .msf file" or "msf of file size=0" instead of "not updated msf file" is observed at above step 2. And some other problems may occur after it. I saw description of the phenomenon in some bugs, and I saw the phenomenon during my duplication test of such bugs with "forced outdated msf condition". I also think above 2(emulation of filter move/junk move/sent mail save) followed by 3 won't produce any problem, if user clicks folder(open folder explicitly) just after that. (Problem of "Corruption of Sent folder around above 2" is already resolved.) However, I think probability of "outdated msf condition at restart of Tb on one of many many peoples" is not negligible, even if probability of "outdated msf condition at restart of Tb on a person" is very very low. Further, as I wrote in bug 422447 comment #14, there is a bug(Bug 480466) who can be a culprit of problem like Bug 462006(truncated prefs.js). This kind of issue can produce issue of "not-saved-msf file" at normal termination of Tb. And, user can't control "filter move/junk move/mail purge/sent mail save without explicit folder open". As David says, I think that improvement is needed around above step 2 & 3.

Hope I'm not going astray here ... xref: bug 429872 - After migration from OE: Contents of imported mail folders are shown once and then never again. Exception produced! bug 472280 - Shredder nightly Cannot move mail to local folder (occasionally) bug 410555 - Titles disappeared in Window when I moved a message to the trash -- nsIMsgFolder.getMsgDatabase]" nsresult: "0x80550005 (<unknown>)" ... chrome://messenger/content/mailWidgets.xml

WADA, I can accept that externally forcing an invalid database is an acceptable simulation of certain rare-but-important bugs involving interrupted file writes. But where we are at today is that the db errors that occur in the error console are part of the expected response. Bienvenu suggests that we "kick off a async parse" but that is not the normal practice, nor is it practical in the vast majority of simple uses. What is practical in the TB3 time frame is to show specific cases of unacceptable behaviour (such as the list in comment 5), and to demonstrate that the same behaviour can be reproducibly caused by externally invalidating the db. We can and should make sure that the error recovery from those situations will not result in unacceptable behavior - though you may still get the error message in the console. "Unacceptable bahavior" would not include an error in counts, nor necessarily a transient failure to display an existing message. "Contents of imported mail folders are shown once and then never again" is an example of an unacceptable result. So my complaint about the current bug is that the combination of 1)forced corruption of db with 2) error message only, without unacceptable behavior, is not something we are likely to fix without a major refactoring of the current db practice. What is the unacceptable behavior of this bug? Please understand that I just want you to use your time effectively, and I am defining "effectively" here selfishly as "give me information that will help me to reproduce an important bug, and motivate me to submit a patch for it" If you can cause an important-but-hard-to-reproduce bug to be reproducible by externally corrupting the db, that is extremely valuable, and the kind of description that I need to get motivated to fix something. rkent

(In reply to comment #6) > But where we are at today is that the db errors that occur in the error console are part of the expected response. Can I construe it as; (a) The exception is simply an error message that (a-1) "outdated msf condition exists" in my case and (a-2) there is no other something wrong in my case. (b) The exception itself never relates to problem of Bug 492344. Note: Because I emulated "auto-compact" by "compact of context menu of a folder without left-click of folder" in test for Bug 492344, the exception was observed always. And Bug 410555 really exists. So I opened this bug separately. (c) The exception in Bug 410555 is probably different reason even if exception itself is reported by same code. (problem is "Titles disappeared in Window") If (a-1)==true&&(a-2)==true, I think better error message is kind for user. But I can accept WONTFIX for (a). If (b)=true and (c) can be said, I can accept INVALID.

Can I construe it as; => Can I construe it as next?

a) 0x80550005 is NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE, which is the expected response if you externally invalidate the msf file. This is more of a status return than an error. There is no reason to believe that anything else is wrong simply from this message. b) "The exception itself never relates to problem of Bug 492344" - I don't know if that is true or not. I suspect many of these bugs are a result of poor recovery from the OUT_OF_DATE or MISSING status return.

(In reply to comment #9) > a) 0x80550005 is NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE, Is there any easy way to change displayed text for caught exeption like next? > 0x80550005 (<unknown>) => 0x80550005 (<NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE>) > I suspect many of these bugs are a result of poor recovery from the OUT_OF_DATE or MISSING status return. "Mouse_Over(catch the exception) + Left_Click_of_Folder(invokes rebuild-index)" correctly recovers from the OUT_OF_DATE status(rebuild-index is properly executed). AFAIR, problem of Bug 492344 couldn't be reproduced, when rebuild-index due to OUT_OF_DATE status is executed by explicit folder open before "folder update without explict folder open when outdated msf condition exist". Bug 492344 is possibly problem in folder-open or rebuild-index or compact-folder. But I think OUT_OF_DATE status is better to be detected/handled at step (2) in comment #4. Should I change bug summary? (current summary can be read "exception occurred!, Tb's bug!".)

After reading answer by Kent James, I tested Bug 492344 without "mouse-over" event. Bug 492344 was produced by next simplest test. 0. Tb knew deleted mails in a folder, Terminate Tb 1. Add mail data to folder file(emulation of outdated msf due to power failure) 2. Restart & File/Compact Folders(No mouse over, then no exception at this step) => Timestamp of msf was updated. Deleted mail was not removed. The exception itself in this case didn't have relation to problem of Bug 492344. So, keep bug summary("exception occurred!, Tb's bug!") for ease of search, and closing as WONTFIX(the exception is simply a message in this bug's case). I'll open separate bug for better detection/recovery from outdated msf. By the way, I saw similar exception upon "Folder Property open / Rebuild Index" after "Compact when outdated msf condition exists". And, when I repeated Rebuild Index, thread pane display was lost(same as "no mails in folder"). Restart was needed to recover from it. I'll open separate bug if it is produced consistently.

FYI. I've opened Bug 494752 for problem when Rebuild-Index.