498814 - "Compact Folder" silently fails and deletes .msf, if mail folder file is opened by other software (in the worst case, generates null mail folder file or deletes mail folder file)

Status: RESOLVED FIXED

(MailNews Core :: Database, defect)

Description

[WADA:World Anti-bad-Duping Agency]

"Compact Folder" silently fails or deletes .msf, if folder open by "Compact FoIder" is interfered with file open by other software.
This is spin off of Bug 493065 Comment #6. (Bug 493065 is opened by opener of Bug 494706. So "interfered by other software" case was tested.)

Checked with next Tb trunk build. Phenomenon(delete of .msf) was observed with Tb 2.0.0.21 too. 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090615 Shredder/3.0b3pre

[Steps to reproduce : Case-1]
(0) A mail folder with some Shift+Deleted mails and remaining mails.
    Number of remaining mail : 0 or more than 1 (NE 1). Restart Tb.
(1) Read open of mail folder file by other program. (Say FN-X)
    (Emulated by Stream("FN-X","C","OPEN READ"); of Open Object Rexx)
(2) "Compact Folder" via context menu (No left click of the folder)
    => FN-X.msf is deleted. Nothing other happens.
(3) Close mail folder file by other program. (Say FN-X)
    (Emulated by Stream("FN-X","C","CLOSE"); of Open Object Rexx)
(4) Move mouse on the folder at folder pane => Next exception
    (Tb detects error condition which is generated by himself.)
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80550006 [nsIMsgFolder.msgDatabase]"  nsresult: "0x80550006 (<unknown>)"
> location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 1951"  data: no]

Note:
Because next error(different problem) occurs after above test with Tb trunk, rebuild-Index and restart of Tb is required to recover from deleted/corrupted .msf.
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80550006 [nsIMsgFolder.msgDatabase]"  nsresult: "0x80550006 (<unknown>)"
> location: "JS frame :: file:///C:/wada/DOWNLOAD/@Mozilla/Thunderbird/@06-15/thunderbird/modules/dbViewWrapper.js :: DBViewWrapper_open :: line 762"  data: no]

[Steps to reproduce : Case-2]
When only one active mail, phenomenon was different. 
(0) A mail folder with some Shift+Deleted mails and remaining mail.
    Number of remaining mail=1. Restart Tb.
(1) Read open of mail folder file by other program. (Say FN-X)
    (Emulated by Stream("FN-X","C","OPEN READ"); of Open Object Rexx)
(2) "Compact Folder" via context menu (No left click of the folder)
    => nstmp, nstmp.msf remained (file size=0 bytes)
    => Next exception occurred.
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.compact]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
> location: "JS frame :: chrome://messenger/content/folderPane.js :: ftc_compactFolders :: line 1619"  data: no]
(3) Close mail folder file by other program. (Say FN-X)
    (Emulated by Stream("FN-X","C","CLOSE"); of Open Object Rexx)
(4) Move mouse on the folder at folder pane => No exception
(5) Click folder => 1 mail, Not compacted
(6) Rebuild-Index => next dialog
>  Alert
>    The operation failed because an other operation is using the folder.
>    Please wait for that operation to finish and then try again.
>                        [ OK ]
(7) OK, Terminate Tb => nstmp, nstmp.msf remained

Comment 1

[WADA:World Anti-bad-Duping Agency]

FYI.
I've opened Bug 498819 for error at dbViewWrapper.js::DBViewWrapper_open::line
762.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Attachment: Process Monitor Log for folder_file/msf and nstmp/nstmp.msf (CSV file)

Folder Files:
  X-1, X-1X : 1 active mail only. (Corresponds to Case-2 in Comment #0)
              3 mails are copied, mail-1, mail-2 is Shift+Deleted.
  X-2, X-2X : 2 active mails.     (Corresponds to Case-1 in Comment #0)
              3 mails are copied, mail-1 is Shift+Deleted.
X-1, X-2  : Compact is executed without interfere.
X-1X,X-2X : Compact is executed with interfere by external software.

Process Monitor Log:
(1) "Compact Folder" of X-1
(2-1) "Open Read" of X-1X by Rexx
(2-2) "Compact Folder" of X-1X
(2-2) "Close" of X-1X by Rexx
(3) "Compact Folder" of X-2
(4-1) "Open Read" of X-2X by Rexx
(4-2) "Compact Folder" of X-2X
(4-2) "Close" of X-2X by Rexx

Comment 3

[WADA:World Anti-bad-Duping Agency]

CC-ing to owner of Bug 387502(David:B) and Bug 494706(Ikezoe-san).

By code change from Tb 2 to Tb 3 in nsMsgLocalMailFolder::CopyFileMessage(see bug 494706 comment #65), Tb 3 issues warning message when write open failure and never goes to next steps, then problem like data corruption will not occur on Tb 3 when mail copy.
I think similar change is required in "Compact Folder" and "Rebuild Index".

Comment 4

[WADA:World Anti-bad-Duping Agency]

Attachment: Rough process monitor log analysis (X-2X case of Comment #2)

Note: Timestamp, process number in Process Monitor log is omitted.
      Path name of C:\...\X-2X is shorten to string like ~\X-2X.

When open failure occurs on X-2X, no data is written to nstmp-1(file_size of nstmp-1==ZERO).
If X-2X is closed by external software just before "delete of X-2X" step, delete of X-2X is executed successfully, then "rename nstmp-1 X-2X" will be executed for nstmp-1 of file_size=0.
It'll cause phenomenon of Bug 492254 / Bug 493065.

Comment 5

[WADA:World Anti-bad-Duping Agency]

If ".msf" file is interfered(opened) by other software, next error is reported to Error Console upon mouse over of mail folder at folder pane.
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80550005 [nsIMsgFolder.getMsgDatabase]"  nsresult: "0x80550005 (<unknown>)"
> location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 2061"  data: no]
In this case, "compact" does do nothing, because write open of msf file fails.
I think all of next should be ensured before start of compaction process.
  1. Update lock of MailDB for mail folder XXX
  2. "Write open" of XXX.msf
  3. "Write open" of XXX
  4. Creation & "Write open" of both nstmp(-N) and nstmp(-N).msf
And, error check and backout/redo/retry like operation is needed in next steps.
  5. Delete of XXX.msf, XXX
  6. Creation/re-open of XXX.msf
  7. Rename of nstmp(-N) to XXX
  8. Re-open of XXX
 (9. Deletion of nstmp(-N).msf, and deletion of nstmp(-N) if remained)

Comment 6

[WADA:World Anti-bad-Duping Agency]

Bug 491303 is first report of file_size=ZERO after compact older while other program is reading mail folder file. Patch for bug 491303 probably resolves all problems I described in this bug.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Bug 491303 was already FIXED by David on 2009-06-26 (Target Milestone: Thunderbird 3.0b3).

Comment 9

[Wayne Mery (:wsmwk)]

wada, excellent analysis as always! :)

before I act to confirm bug 493065 and bug 500108, is there any reason not to do so?

Comment 14

[WADA:World Anti-bad-Duping Agency]

If correct exception handling in all open/write/read/close file steps is hard, following may be a simple workaround of "mail folder file size=0" case.
1. if ( all mails in Inbox were deleted )
   { truncate Inbox at offset=0; initialize .msf; exit; }
2. var minimum_size = size of shortest mail which doesn't have expunged bit=On;
3. do same steps as current, except "delete Inbox + rename nstmp Inbox" step.
4. if ( file size of nstmp < minimum_size )
        { skip "delete Inbox + rename nstmp Inbox" step }
   else { execute "delete Inbox + rename nstmp Inbox" step as current }

Comment 15

[David :Bienvenu]

We do verify that the tmp file size is the right size before copying it over the original folder. See http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#455

Comment 16

[WADA:World Anti-bad-Duping Agency]

m_totalMsgSize is set at here(in nsFolderCompactState::EndCopy).
> http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgFolderCompactor.cpp#1146
Is m_totalMsgSize correct even when file open(perhaps shared write) of mail folder file fails due to write or read open by other software?

Comment 17

[WADA:World Anti-bad-Duping Agency]

Quick check result with Tb 11.0.1.
"SHARING VIOLATION upon write open of folder file" looks correctly processed as error and feeded back to requester of Compact, but other problem occurred.

1. XYZ is file name, and is opened by Object Rexx.
2. Compact of XYZ
3. nstmp, nstmp.msf is created. no data is written to file.
4. Shared Read/Write mode open of XYZ by Tb => 	SHARING VIOLATION 
> IRP_MJ_CREATE	SHARING VIOLATION Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a	304	1728
5. Following exception is reported to Error Console.
> Timestamp: 2012/04/05 11:44:18
Error: uncaught exception:
>  [Exception... "Component returned failure code: 0x8052000e (NS_ERROR_FILE_IS_LOCKED) [nsIMsgFolder.compact]"
>  nsresult: "0x8052000e (NS_ERROR_FILE_IS_LOCKED)"
>  location: "JS frame :: chrome://messenger/content/folderPane.js :: ftc_compactFolders :: line 2287"  data: no]
6. No file related request after it on nstmp, nstmp.msf, XYZ, XYZ.msf.
   Compact silently failed except message in Error Console, 
   and generated garbage of nstmp/nstmp.msf. 

Open error is perhaps returned by next code.
> http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsLocalMailFolder.cpp#693
> 693     return msgStore->CompactFolder(this, aListener, aMsgWindow);
And exception is perhaps reported while execution of next code.
> http://mxr.mozilla.org/comm-central/source/mail/base/content/folderPane.js#2298
> 2298       folders[i].compact(null, msgWindow);

7. After it, Repair Folder, Compact of XYZ failed with next message.
> The operation failed because another operation is using the folder. Please wait for that operation to finish and then try again.
> The folder 'XYZ' cannot be compacted because another operation is in progress. Please try again later.

In Tb 11 on Win, file size=0 can't occur, because exception happens when interfered by other software's file open.
I don't know what will happen if "another operation"(perhaps unreleased "folder lock" like resource), exceptions during Compact logic execution, will be resolved.

I'll open separate bug for above phenomenon, because bugs for actual "file size=0" are already duped to this bug.

Comment 18

[WADA:World Anti-bad-Duping Agency]

Pasted string of "Gecko/20090615 Shredder/3.0b3pre" in comment #0 is wrong, and typed "Tb 2.0.0.21" is correct Tb version when I posted comment #0, and attached Process Monitor log is obtained with Tb 2.
So I checked with 1.9.1 20090701 build(3.0b3pre) and trunk 20091230 build(3.1a1pre).
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090701 Shredder/3.0b3pre
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091230 Shredder/3.1a1pre
- 1.9.1 20090701 build : after Bug 491303 is fixed. 
- trunk 20091230 build : final 3.1a1pre build.
- Patch for Bug 491303(tmp file size check is introduced, fixed on 2009-06-26)
  is already applied to both builds.

Same result as Tb 11.0.1, except error message in Error Console(line number depends on build).
> Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.compact]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/folderPane.js :: ftc_compactFolders :: line XXXX"  data: no]

Tb 3.0/3.1 behaviour in Process Monitor log was same as Tb 11.0.1. 
Tb 2 went ahead to "close nstmp" step with no data write to nstmp and went ahead "delete XYZ + rename nstmp XYZ" step even after SHARING VIOLATION of XYZ, but Tb 3.0/3.1/11.0.1 stops any further step after SHARING VIOLATION of XYZ, including file close, delete of nstmp/nstmp.msf.

As Bug 494706 1.8 branch only problem, "no error check in folder file open" looks 1.8 branch only problem too.
Sorry for my confusion.
I should have stooped duping of bugs for actual file size=0 cases to this bug...

Comment 19

[WADA:World Anti-bad-Duping Agency]

FYI.
Once "SHARING VIOLATION" occurs on mail folder file in Compact of Tb 3.0 and later, "another operation is using the folder" or "another operation is in progress" continues to occur until restart of Tb, in any of mail copy/move to the folder, Repir Folder(Rebuild Index), Compact.

Comment 20

[WADA:World Anti-bad-Duping Agency]

Behaviour of Tb 3.0b2pre 20090101 build was different from Tb 3.1/Tb 11.0.1, and was rather similar to Tb 2.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090101 Shredder/3.0b2pre

1. Read open of XYZ by tool
2. Compact. Tb goes ahead even when "SHARING VIOLATION" occurs on XYZ.
3. delete/create XYZ.msf occurs. file size of XYZ.msf=0.
   nstmp/nstmp.msp is not deleted.
   thread pane becomes blank.
4. terminate Tb => file size of XYZ.msf = 2KB. Same as initialized .msf file.
5. close XYZ by tool 
6. restart Tb, Compact XYZ => nohing happens. thread pane is still blank.
7. copy a mail to XYZ folder => all mail is shown at thread pane.
   Internal rebuild-index is perhaps invoked.

If file is closed in other software just before delete XYZ/XYZ.msf + rename nstmp/nstmp.msf to XYZ/XYZ.msf, file size=0 of XYZ can happen.
If Compact happens after 0 bytes XYZ.msf is written and if file is alreay closed by other software, Compact may clear XYZ file and may produce file size=0.

If Tb 3.0xpre, behavior depends on build. So, bug report of file size=0 for Tb 3.0xpre should be carefully analyzed.


.

Comment 21

[WADA:World Anti-bad-Duping Agency]

Checked next builds.
> Gecko/20090602 Shredder/3.0b3pre : because bug opener of bug 500109 used Gecko/2009060215 Firefox/3.0.11 when the bug was opened
> Gecko/20090615 Shredder/3.0b3pre : because I pasted it in comment #0
Tb's behavior was same as Tb 3.1/Tb 11.0.1. Nothing is executed by Tb on mail folder files after "SHARING VIOLATION".
I believe that bug 500109 can't be same as "possible file size=0 by Compact of Tb 2 in this bug", because that bug was opened on 2009-06-23 and bug opner used Firefox 3.11 build on 2009-06-02.

Comment 22

[WADA:World Anti-bad-Duping Agency]

Checked 3.0b3pre 20090501 build.
> rv:1.9.1b5pre) Gecko/20090501 Shredder/3.0b3pre :
>    because bug 491303 was opened on 2009-05-04, for "Shredder 3.0b3pre"
Tb's behavior was same as Tb 3.1/Tb 11.0.1. Nothing is executed by Tb on mail folder files after "SHARING VIOLATION".

By some changes after "Gecko/20090101 Shredder/3.0b2pre", nothing was executed on mail folder files after "SHARING VIOLATION" at least by Gecko/20090501 Shredder/3.0b3pre or later. So, bug 491303, which already did nstmp file size check I proposed in comment #14, was not report of "file size = 0 due to lack of nstmp file size check in Compact".

(In reply to David :Bienvenu from comment #15)
> We do verify that the tmp file size is the right size before copying it over
> the original folder.

I didn't understand patch for bug 491303, so I wrote comment #14.
And, I wrongly thought that "potential file size = 0 by Compact due to other software's interfere" surely occurred in Tb 3.0b3pre 20090501 build, by your patch proposing to bug 491303 which is report for Tb 3.0b3 build(in which, file size=0 couldn't occur), and by B.M.O term of FIXED. I wongly thought "bug 491303 was actually fixed by your patch proposed to bug 491303".
David, your patch of bug 491303 should have been proposed in 
bug 492254(for rv:1.8.1.21 Gecko/20090403 SeaMonkey/1.1.16) or bug 493065(for Tb 2.0.0.21 20090302), or in this bug(for Tb 2.0.0.21) before my proposal of comment #14 :-)

Anyway, I could now sort out issue of "potential file size = 0 by Compact due to other software's interfere" by your notification about already existent m_totalMsgSize. Thanks for your pointing to m_totalMsgSize.

Comment 23

[WADA:World Anti-bad-Duping Agency]

Because recent Tb's exception is different from Tb 2/3 era, and because file size=0 by Compact currently can't occur if mail folder file is interfered by other software, and because nstmp file size check is already done by patch for bug 491303, and because attached Process Monitor log of Tb 2 is misleading, I'll open new bug for "silent Compact failure if interfered by other software in Tb 11 or later" with removing "file size=0" part, and I'll change this bug to "Tb 2 only bug"(two bugs were already dup'ed) and will close this bug.

Comment 24

[WADA:World Anti-bad-Duping Agency]

Attachment: Problem analysis by Andrew in bug 674742 comment #23

Bug 674742 is for "mbox file deletion by Compact if mbox file is encrypted on Win-2K". In that bug, mechanism was analyzed by bug opener. Attached is the problem analysis by Andrew in bug 674742 comment #23.
According to the analysis, similar problem to this bug may occur if interfere by someone on mbox.msf/mbox/nstmp.msf/nstmp happens at other steps of Compact.

Comment 25

[WADA:World Anti-bad-Duping Agency]

Sorting out of Compact logic, proper error handling etc. are proposed in bug 674742. Setting dependency to that bug for ase of tracking and analysis.

Comment 26

[WADA:World Anti-bad-Duping Agency]

Attachment: Process Monitor log : Tb 14.0 Normal Compact of mbox(BBB.sbd\XXX)

Comment 27

[WADA:World Anti-bad-Duping Agency]

Attachment: Process Monitor log : Tb 14.0, Interfere of Compact of mbox(BBB.sbd\XXX) by "Open Write Exclusive"open

(1) When \BBB.sbd\XXX is opened by Rexx program("Open Write Exclusive" mode) before Tb 14.0 starts Compact of XXX under BBB,
(1-1) Following exception is reported to Error Console.
> Error: NS_ERROR_FILE_IS_LOCKED: Component returned failure code: 0x8052000e
> (NS_ERROR_FILE_IS_LOCKED) [nsIMsgFolder.compact]
> Source File: chrome://messenger/content/folderPane.js Line: 2295
(1-2) nstmp/nstmp.msf is not deleted after Compact failure.
        => after restar of Tb, mail folder named "nstmp" appears. 
      File size of nstmp/nstmp.msf = 0.
      \BBB.sbd\XXX/\BBB.sbd\XXX.msf is unchanged.
(2) After Rexx program closes \BBB.sbd\XXX file,
    XXX is normally accessed by Tb 14.0.

Critical problems looks resolved already and remaining problem seems "undeleted nstmp/nstmp.msf" only in Tb 14.

Comment 28

[WADA:World Anti-bad-Duping Agency]

Compact roughly consists of;
(1) from original/original.msf, create compacted version of nstmp/nstmp.msf.
(2-a) rename nstmp to original with replace mode.
      (if Win, MoveFileExW with replace mode)
(2-b) rename nstmp.msf to original.msf with replace mode.
      (if Win, MoveFileExW with replace mode)

This bug was initially for "open failure of original at step (1)" which can manually/externally be forced easily.

As reported in bug 674742(if Win-2K which is not supported any more, and if original is enchrypted, MoveFileExW fails, then nstmp is not successfully renamed to original), if step (2-a) fails, nstmp is deleted by Compact, and original is not kept as-is or is deleted by Compact.

Above "rename failure at step (2-a) and/or step (2-b)" can occur in any environment if auto-backup/virus scanner runs on Tb's mail folder files, because;
- all of original/original.msf/nstmp/nstmp.msf is closed
  after step (1) and before step(2), in order to do "rename".
- auto-backup/virus scanner etc. can open any of original/original.msf
  /nstmp/nstmp.msf after step (1) and before step (2-a)/(2-b) by Tb.
So, loss of original and nstmp can occur if step (2-a) is interfered by other software.

Bug 789754 is for this "loss of original and nstmp when rename failure in step (2-a)".
Setting dependency to Bug 789754.

Comment 29

[Hiroyuki Ikezoe (:hiro)]

(In reply to WADA from comment #28)
> Compact roughly consists of;
> (1) from original/original.msf, create compacted version of nstmp/nstmp.msf.
> (2-a) rename nstmp to original with replace mode.
>       (if Win, MoveFileExW with replace mode)
> (2-b) rename nstmp.msf to original.msf with replace mode.
>       (if Win, MoveFileExW with replace mode)
>
> Bug 789754 is for this "loss of original and nstmp when rename failure in
> step (2-a)".
> Setting dependency to Bug 789754.

Thanks for the summary.
And I am sorry the summary for bug 789754 was misleading. It actually covers (2-b) at least the fix for the bug coverts (2-b). So you can close the bug 78594 as a duplicate, or vice versa.

Comment 30

[Hiroyuki Ikezoe (:hiro)]

Ooops! I missed (1) issue.. Never mind.

Comment 31

[WADA:World Anti-bad-Duping Agency]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #29)
> So you can close the bug 789754 as a duplicate, or vice versa.

Ikezoe-san, I recommend you to propose your patch in this bug instead of bug 789754 which can cause annoying comment like bug 789754 comment #1 :-)

Comment 32

[Hiroyuki Ikezoe (:hiro)]

(In reply to WADA from comment #31)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #29)
> > So you can close the bug 789754 as a duplicate, or vice versa.
> 
> Ikezoe-san, I recommend you to propose your patch in this bug instead of bug
> 789754 which can cause annoying comment like bug 789754 comment #1 :-)

I am also considering it but Mark has started to solve that bug so I should be quiet for a while.

Comment 33

[WADA:World Anti-bad-Duping Agency]

Although "potential loss of mail folder file at step (1)" is Tb 2 only problem,
"potential loss of mail folder file at step (2-a)/(2-b)" remains in Tb 3 and newer as reported in bug 674742.
So removing "Tb 2" from bug summary, white board.

Comment 34

[WADA:World Anti-bad-Duping Agency]

Bug 789754 was closed as dup of bug 674742.

Comment 35

[Wayne Mery (:wsmwk)]

wada, in your opinion, is this bug greatly helped by bug 674742?
and is it potentially gone?

Comment 36

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk) from comment #35)
> wada, in your opinion, is this bug greatly helped by bug 674742?
> and is it potentially gone?

I can't say nothing about the patch, because I don't know what is actually done by Tb at OS's API level after the patch is applied.
But I believe patch of bug 674742(in my opinion, patch should have been proposed in Bug 789754 or this bug) removed potential msgFolder file loss by Compact what I mentined in this bug, and I hope that my belief is correct.

AFAIK, changes for "potential ZERO bytes msgFolder file" are;
  (1) patch of Bug 491303
      Check nstmp size with "expected size", and if different, discard nstmp.
  (2) patch of bug 674742
Characteristics of changes. 
  (1) is applicable to ""copy from original to nstmp" phase only.
  (1) can do nothing on interfere during "rename nstmp & nstmp.msf to original
      folder name" phase.  
  (2) cares for both phases.
Changed landed on;
  (1) Thunderbird 3.0b3
  (2) Thunderbird 17
I believe number of bug reports for actual msgFolder file size=ZERO problem, with auto-bakup, virus- scan, was reduced by (1), but such reports actually existed after (1).
I don't see such reports after Tb 17.
However, Tb 17/18/19 is not baked sufficiently long yet.

Because RESOLVED/FIXED status tends to produces confusion with VERIFIED/FIXED and tends to misinterpretation of RESOLVED/FIXED(it means merely patch was landed, no garantee of problem reported to the bug is actually resolvd) as "VERIFIED/FIXED"(patch has been landed, "at least cared case in the bug is actually resolved by patch" was verified by test), I can't close this bug as FIXED by that patch yet.

Comment 37

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #36)
> (In reply to Wayne Mery (:wsmwk) from comment #35)
> > wada, in your opinion, is this bug greatly helped by bug 674742?
> > and is it potentially gone?
> 
> I can't say nothing about the patch, because I don't know what is actually
> done by Tb at OS's API level after the patch is applied.
> But I believe patch of bug 674742(in my opinion, patch should have been
> proposed in Bug 789754 or this bug) removed potential msgFolder file loss by
> Compact what I mentined in this bug, and I hope that my belief is correct.
> 
> AFAIK, changes for "potential ZERO bytes msgFolder file" are;
>   (1) patch of Bug 491303
>       Check nstmp size with "expected size", and if different, discard nstmp.
>   (2) patch of bug 674742
> Characteristics of changes. 
>   (1) is applicable to ""copy from original to nstmp" phase only.
>   (1) can do nothing on interfere during "rename nstmp & nstmp.msf to
> original
>       folder name" phase.  
>   (2) cares for both phases.
> Changed landed on;
>   (1) Thunderbird 3.0b3
>   (2) Thunderbird 17
> I believe number of bug reports for actual msgFolder file size=ZERO problem,
> with auto-bakup, virus- scan, was reduced by (1), but such reports actually
> existed after (1).
> I don't see such reports after Tb 17.
> However, Tb 17/18/19 is not baked sufficiently long yet.

wada, Now that we're in TB24, almost TB31, what is your assessment - are we still seeing reports of this?

Comment 38

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk) from comment #37)
> - are we still seeing reports of this?

I didn't test this bug again.
"Step to reproduce" is pretty simple. i.e. Anyone can do duplication test pretty easily.
Must bug opener do duplication test with any Tb release always in B.M.O?

Comment 39

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #38)
> Must bug opener do duplication test with any Tb release always in B.M.O?

Must? no.
Is it always helpful?  yes :)
Always your choice.

But when you prefer that someone independently attempt to reproduce, it would be helpful to say that also.

If STR is not comment 0, then please update whiteboard. THanks.

Comment 40

[:aceman]

This should really be retested with current TB. As it seems bug 674742 may have helped this radically. As far as I can read the code it does this after the nstmp files are done:
1. moves original .msf to a new random filename (which hopefully detects if another program is holding the file).
2. tries to move new nstmp to the original folder file name
2a) if that fails (should probably detect that some other program is holding the file), it should clean up after itself, deleting nstmp and nstmp.msf thus aborting compact.
2b) if it succeeds, the moves the new .msf to the right name of folder.msf.

Comment 41

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #40)
> This should really be retested with current TB. 

Following part in bug summary was written based on my quick code reading.
> (in the worst case, generates null mail folder file or deletes mail folder file)
I think this worst case was perhaps resolved by bug 674742, but I was not sure, so I kept this bug open.

I believe your code reading is accurate. Closing as "fixed by bug 674742".