Closed Bug 493065 Opened 15 years ago Closed 13 years ago

automatic compact deletes folders (without creating nstmp) if something is done to folder during compact process ("Memeo AutoBackup" is used for auto-backup)

Categories

(MailNews Core :: Database, defect)

Product:
MailNews Core
Component:
Database
Version:
1.8 Branch
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 498814

People

(Reporter: ekhart.georgi, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.21 (20090302)

Thunderbird destroys folder when compacting if something is done to folder during compact process. No nstmp file found, and inbox file (or sent file etc.) 0 kB. 
I've heard of this problem once in a while in different forums and personally experienced several instances during last three years: Apparently twice caused by tagging message, once caused by simply reading and scrolling, once caused by PerfectDisk defrag in background, and once caused after turning on "allow antivirus to quarantine..." with AV that does not even check incoming emails but interrupted email download with virus warning(!) (I didn't even know this made it possible for AVs that have no email scanning to analyse mail! I immediately turned it off again.)

Similar reports are in forums e.g. http://forums.mozillazine.org/viewtopic.php?f=39&t=1003705&start=0 and bug 396470 and in some bug reports that do not mention compacting but that describe situations where it's very probable: Bug 489145, bug 424518 

Reproducible: Didn't try

Steps to Reproduce:
1. Set automatic compact to fairly high value (1000 kB or more) to ensure long compacting process when it starts
2. Tag messages or delete messages during compact process, apparently after it has started (apparently running defrag program can also make TB destroy a folder)
3. Perhaps the user or other outside action (defrag, antivirus) has to start before or after the compact process starts or perhaps "simultaneously" 
Actual Results:  
Thunderbird deletes folder 

Expected Results:  
Thunderbird should lock folder and prevent access or at least create nstmp folder

default theme, several dictionary add-ons, display mail user agent 1.6.3, external editor 0.7.4
Version: unspecified → 2.0
This bug can no doubt be reproduced at a specific desired time with a manual compact after turning off automatic compacting and deleting a large amount of emails so that the compact process takes as long as possible. Perhaps this is connected to or only occurs if email is being automatically moved to the junk folder.
changed component to General because no component description seems to talk about basic functionality - very confusing
Component: Mail Window Front End → General
QA Contact: front-end → general
Component: General → Database
Keywords: dataloss
Product: Thunderbird → MailNews Core
QA Contact: general → database
Summary: automatic compact deletes folders (without creating nstmp) → automatic compact deletes folders (without creating nstmp) if something is done to folder during compact process
Version: 2.0 → 1.8 Branch
apparently related to bug 368768 due to TB's inability to prevent
access to folders during compact
Ekhart, does your auto-backup software backup nstmp?
Yes, but it doesn't keep more than 3 copies, so the one that may have been created when the inbox was destroyed has long since been replaced by newer ones.
Quick test result of "interfere of compact foler by external software".
  (0) Shift+Delete of some mails at a folder (say Folder-A), Teminate Tb
  (1) Restart Tb
  (2) Read open of file named Folder-A by external software.
      (I emulated it by Stream("Folder-A","C","OPEN READ"); of Open Object Rexx)
  (3) Right click of Folder-A(no left click), "Compact Folder" on Folder-A.
      => "Compact Folder" silently failed
         Folder-A.msf was deleted.
  (4) Close file named Folder-A by external software.
      (I emulated it by Stream("Folder-A","C","CLOSE"); of Open Object Rexx)
  (5) Tb detected "outdated msf condition", but rebuild-index didi't seem 
      to be invoked/executed normally, even when "explicit folder open"
      by left-click of the folder was executed. No mails were displayed in folder
      pane. This was true even after restart of Tb.
      Manual "Rebuild-Index" via "Folder Properties" was required to recover.

Because "corruption of .msf" occurs, something wrong can easily occur, if problem like above occurs.

(In reply to comment #0)
> and inbox file (or sent file etc.) 0 kB.

File named Inbox(or Sent)? Size displayed at where? Windows Explorer's "folder listing"? (I could see Folder-A.msf with file_size=0 during above test.)
Same phenomenon as Comment #6 was observed by replacing "manual Compact Folder" with "manual Rebuild-Index". Problem of Comment #6 may be said as follows:
  - Open failure by "Compact Folder" and "Rebuild-Index" produces "corrupted msf".
  - Once "corrupted msf" by them is generated, internal rebuild-index can't recover
    from it upon folder open.
  - Manual Rebuild-Index before explicit folder open(before detection of corrupted
    or outdated msf) is required to recver.
I'll open separate bug(s) for it.
As seen in Case-2 of Bug 498814 Comment #0, there is timing of "nstmp of file_size=0" exists. If file lock by auto-backup is released just before "delete of folder_file and rename of nstmp to folder_file" step of "Compact Folder", "folder_file of file_size=0" is possibly generated.
Summary: automatic compact deletes folders (without creating nstmp) if something is done to folder during compact process → automatic compact deletes folders (without creating nstmp) if something is done to folder during compact process ("Memeo AutoBackup" is used for auto-backup)
No longer blocks: 492254
Depends on: 492254
Bug 492254 reported similar phenomenon with Seamonkey(auto-backup is used too).
consolidating / dup to bug 498814
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
No longer depends on: 498814
You need to log in before you can comment on or make changes to this bug.