Empty inbox file created during virus scan and compact

RESOLVED FIXED in Thunderbird 3.0b3


10 years ago
7 years ago


(Reporter: herm.harrison, Assigned: Bienvenu)



1.9.1 Branch
Thunderbird 3.0b3
Windows Vista

Firefox Tracking Flags

(Not tracked)



(1 attachment)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4
Build Identifier: Shredder 3.0b3pre

All messages in inbox disappear and inbox file is replaced with an empty file.  This is the second occurrence.  It appears to be related to an interference with Sunbelt Software's VIPRE anti-virus which was scanning the mail folder on or about the same time the file disappeared.

Folder appeared to be compacting and when complete,it was entirely empty, previously about 51 MB with approximately 200 messages.  Sunbelt disavows any responsibility indicating that they do not interface directly with Thunderbird.  I do, however, believe the scan and disappearance are related.

Reproducible: Sometimes

Steps to Reproduce:
1. Reviewing messages in inbox.
2. Delete a message or take other action.
3. Inbox file disappears and is replaced with an new, empty file.
Actual Results:  
All saved messages in inbox disappear.  Have had the same thing occur in junk folder.

Expected Results:  
Expected message to be deleted with no other changes.

Appears to possibly be related to a virus scan.  On both occasions, anti-virus program was scanning the AppData folder (Windows Vista) and may have been scanning the inbox and or junk files at the time the problem occurred.

Could it be that Shredder is unable to access the inbox or other folders for some reason, assumes they are missing or corrupt and creates new ones?
see bug 409944
Last Resolved: 10 years ago
Resolution: --- → INVALID

Comment 2

10 years ago
I will add that Sunbelt VIPRE does not detect any virus or quarantine any files so I don't know if bug 409944 is the answer.  Thunderbird is configured to download the files individually, and it appears that the messages remain in the inbox.mozmsgs folder.  Only the inbox is vacated.
Resolution: INVALID → ---
pop or imap?

Comment 4

10 years ago
pop3 account.  I have changed the server settings to keep messages on server for 7 days until a resolution to this issue has been reached.
Reporter..is this you here:

If not, it seems like a related problem with "windows search"
Inbox.mozmsgs is a folder created by Thunderbird for Windows Search integration. wdseml files don't contain entire messages, only relevant parts. Attachments, for example, are stripped out.

I doubt that Windows Search integration has anything to do with your problem, as it doesn't write to the mbox files at all, only reads from them.

Comment 7

10 years ago
Responding to comment #5, I did post the question on the forum and also the "solution" that I found.  Agreeing with comment #6, the files contained in the *.mozmsgs files aren't a total solution, but at least they do allow a user to find out what is missing and contact the original sender, if need be to recover an attachment, etc.

I do not believe the Vista or Windows search integration is part of the problem, but if this feature is enabled, it may provide, as it did in my case, a solution to recover messages lost when an mbox folder is corrupted, overwritten, or missing.
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Version: unspecified → 1.9.1 Branch
David what would you need to figure out what is going on ?

Comment 9

10 years ago
Virus checkers do delete files when it looks like a virus is written to them - we've seen it over and over again. In this case, it sounds like it's interfering with folder compaction. We could try to check that the tmp file is roughly the right size before copying back over the original Inbox/folder.
Ever confirmed: true


10 years ago
Keywords: dataloss
Summary: Empty inbox file created during virus scan. → Empty inbox file created during virus scan and compact

Comment 10

10 years ago

Is there something that I can check for you?  The tmp file may now be gone, but if I know what I'm looking for, I can check, or at least locate it if the issue presents itself to me again.

Comment 11

10 years ago
Herm, I doubt there's much you can see, since the virus checker isn't inclined to leave any files around :-(

Comment 12

10 years ago
Created attachment 378053 [details] [diff] [review]
make sure the tmp file is the right size before copying back over the original

I don't know if this will help, but it verifies that the tmp file we copy undeleted messages to is the right size, before copying back over the original folder (in this case, the inbox). I'll try running with this patch, though I never see the original problem...
Assignee: nobody → bienvenu


10 years ago
Attachment #378053 - Flags: superreview?(neil)
Attachment #378053 - Flags: review?(bugzilla)
So this way the compact just fails if the size mismatches?

Comment 14

10 years ago
yes - we could be more forgiving and just check for 0 size, I suppose, but the size really should match, and if something interfered with the compact, it's probably better just to back off and do it the next time - I suppose we should put something in the activity manager...in fact, compact should probably go there anyway.
(In reply to comment #0)
> inbox file is replaced with an empty file. 
> It appears to be related to an interference with Sunbelt Software's VIPRE anti-virus
> which was scanning the mail folder on or about the same time the file disappeared.

Sounds to be same issue as Bug 492254 / Bug 493065.
Herm(bug opener), do you use auto-compact? Did you force silent auto-compact?
Check next settings via Config Editor. 
> mail.prompt_purge_threshhold : true/false
> mail.purge_threshhold        : NNN (in KB, Kilo-Bytes)
> mail.purge.ask               : true/false

Comment 16

10 years ago

These are the current settings.  Settings at the time of data loss were:

I can say nothing about what really happened, but I can say that possibility of phenomenon I explained in Bug 498814 Comment #4 is not ZERO, because;
  - auto-compact was on and was silent-auto-compact
  - just after mail delete operation
  - anti-virus software was scainning files
Setting dependency to 498814. Please reset it if wrong.
Depends on: 498814


10 years ago
Attachment #378053 - Flags: superreview?(neil) → superreview+
Attachment #378053 - Flags: review?(bugzilla) → review+

Comment 18

10 years ago
fix checked in.
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b3
Blocks: 498814
No longer depends on: 498814
You need to log in before you can comment on or make changes to this bug.