lost mail in inbox after a compact

VERIFIED DUPLICATE of bug 136784

Status

--
critical
VERIFIED DUPLICATE of bug 136784
17 years ago
5 years ago

People

(Reporter: tim, Assigned: naving)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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".

Comment 1

17 years ago
-> Navin
Assignee: bienvenu → naving
Status: UNCONFIRMED → NEW
Component: Mail Database → Mail Back End
Ever confirmed: true

Updated

17 years ago
QA Contact: gayatri → sheelar
(Assignee)

Comment 2

17 years ago
Did you start compact when we were rebuilding summary file for Inbox ?
(Reporter)

Comment 3

17 years ago
i dont think so, but its possible

Comment 4

17 years ago
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?
(Reporter)

Comment 5

17 years ago
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.

Comment 6

16 years ago
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.
(Assignee)

Comment 7

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 8

16 years ago
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.