Closed Bug 396470 Opened 17 years ago Closed 14 years ago

Inbox deleted as part of a folder compaction

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Version:
1.8 Branch
Platform:
x86
Windows Server 2003
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: baffoni, Unassigned)

Details

(Keywords: dataloss)

Seamonkey 1.1.4. I have now had two users lose the entire contents of their inbox after doing a folder compaction. The first user happened to be doing the compacting during a backup and I wrote it off as a weird file locking issue, and as there was no data loss (after restore) ignored it. But this second user now has lost her Inbox and did NOT have a backup running at the time of compacting. There was no leftover nstemp file, no orphaned inbox<something> file. After hitting compact, the entire contents of the inbox were gone, and new email starting coming into the new 0length inbox file.
Assignee: general → nobody
Component: General → MailNews: Backend
Product: Mozilla Application Suite → Core
QA Contact: general → backend
Is it possible anti-virus software was involved?
Nope, those folders are excluded from virus scanning (man that does BAD things to performance any time an email is received or sent!).
Product: Core → MailNews Core
If this is imap, how could data be permanently be gone from server due to compact?? Doesn't sound credible to have been caused solely by Thunderbird.
In this case, the folders were local. We have since primarily moved to IMAP, but some users still keep a few local folders. That said, I haven't had any repeats (thank goodness) so far, so this might be limited to the two occurrences on two different machines. Reducing the amount of local storage may also have an effect perhaps.
WFM per comment 4
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.