Closed Bug 146414 Opened 22 years ago Closed 22 years ago

lost mail in inbox after a compact

Categories

(MailNews Core :: Backend, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 136784

People

(Reporter: tim, Assigned: naving)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1)
Gecko/20020417
BuildID:    2002041711

Not sure why it didt compact properly, but i thought i lost a few hundered. I
wanted to make absolutely sure so i check the dir and inbox was 0k, after i
stopped swearing, i saw a nstemp file which was 23 meg, i thought to myself what
if that is the inbox prior to compacting it, so i renamed it to inbox and bingo
there my mail was. You might want to think about putting checks for the file and
if it exists determine what it is meant to be and rename it so that an
inexperienced user doesnt lose any important email.

Reproducible: Couldn't Reproduce
Steps to Reproduce:
1.Compacted Inbox
2.Started Swearing as the inbox that shoul have over 400 messages was empty


Expected Results:  Checks for the existance of the nstemp file and restore it if
applicable (maybe prompt user "the last compact appears to have failed, a copy
of the folder <foldername> has been found, would you like to restore it".
-> Navin
Assignee: bienvenu → naving
Status: UNCONFIRMED → NEW
Component: Mail Database → Mail Back End
Ever confirmed: true
QA Contact: gayatri → sheelar
Did you start compact when we were rebuilding summary file for Inbox ?
i dont think so, but its possible
Bug 136784 was fixed 04-15 and the reporter has build id from 04-17. So could
this be some other scenario where compaction still has this problem?
Reporter,
Are you sure it is the correct build id that you saw this problem with?
yep, it was buld 2002041711 aka Mozilla 1.0 RC1 (i am still using this build as
well), im not sure if its exactly the same as bug 136784 as that just said it
left the nstemp file, under win2k and no mail was lost, the inbox database was
0kb and the nstemp was 23meg.
The same thing just happened to me, on the official 1.0 release on Win32. I said
'Yes' to compact while it was downloading messages. Could you at least disable
autocompaction while downloading messages as a stopgap measure? This bug is
*extremely* malign (as in, I almost tossed my monitor through the window just now).

Incidentally, while nstemp saved my old Inbox, the newly arrived messages (which
I really wanted to read) were irretrievably nuked.
I'm going to dup this bug to bug 136784 because we were not handling invalid
summary files propoerly and it was checked on 1.0 branch on 6/24. Please use
latest trunk builds and/or wait for next milestone release. Don't use mozilla
1.1 alpha, that has other compact bug 150716. 

*** This bug has been marked as a duplicate of 136784 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
vrfy dup
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.