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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
pop or imap?
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: http://forums.mozillazine.org/viewtopic.php?f=39&t=1230495&start=0&st=0&sk=t&sd=a 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.
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 ?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Empty inbox file created during virus scan. → Empty inbox file created during virus scan and compact
David, 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.
Herm, I doubt there's much you can see, since the virus checker isn't inclined to leave any files around :-(
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
So this way the compact just fails if the size mismatches?
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
mail.prompt_purge_threshhold;false mail.purge.ask;false These are the current settings. Settings at the time of data loss were: mail.prompt_purge_threshhold;true mail.purge_threshhold;5000 mail.purge.ask;false
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
Attachment #378053 - Flags: superreview?(neil) → superreview+
Attachment #378053 - Flags: review?(bugzilla) → review+
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b3
You need to log in before you can comment on or make changes to this bug.