Closed Bug 173357 Opened 20 years ago Closed 20 years ago

Compacting folders when getting lock failed

Categories

(MailNews Core :: Backend, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: naving, Assigned: naving)

References

Details

(Keywords: dataloss, Whiteboard: [ish1+][fixedish1])

Attachments

(1 file)

I found a major hole in compacting folders. When we don't get the lock we still
continue to compact, issuing more than one compact etc. bad bug!!
Attached patch proposed fixSplinter Review
We should return not fall through after calling compactNextFolder. major
hole...
causing real bad bugs.
cc cavin & bienvenu for reviews ? thx.
Status: NEW → ASSIGNED
QA Contact: gayatri → esther
do we try to compact the same folder again, or the next folder in the list? Why
does failing to get the lock on one folder affect the compaction of the next
folder? Or is there some other problem? Your change seems OK, but I'm curious
about the details.
The details are self explanatory. We issue compact for next folder and then
comeback and compact the folder for which lock failed. 
cc putterman. Scott, we need this for blackbird. 
well, it may be self-explanatory to you, but the way I imagine compact all
working is one folder after the other. So, I do folder A, then I do folder B,
then folder C. If folder A fails, then I should move on to folder B.
ah, so what's the affect of your change? Do we abort all the compacts, or just
the current compact, and go on to the next folder?
So if folder A fails we move on to folder B but because we don't return after
calling CompactNextFolder() we were compacting A. So 2 compacts for A & B issued
at the same time and compact for A doesn't even have the lock. 
With my current we just abort current compact. 
s/current/change
Comment on attachment 102245 [details] [diff] [review]
proposed fix

well, I still can't tell for sure if we go on to compact the next folder or
not, but at this point, anything is better than what must be happening without
this patch. I think it would probably be better to continue on to the next
folders, and I'm guessing that's what happens.
Attachment #102245 - Flags: superreview+
Comment on attachment 102245 [details] [diff] [review]
proposed fix

r=cavin.
Attachment #102245 - Flags: review+
I meant we skip the current folder and compact the next folder. 
fix checked in. 
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 170600 has been marked as a duplicate of this bug. ***
*** Bug 164624 has been marked as a duplicate of this bug. ***
*** Bug 144561 has been marked as a duplicate of this bug. ***
*** Bug 137139 has been marked as a duplicate of this bug. ***
Keywords: adt1.0.2
*** Bug 152101 has been marked as a duplicate of this bug. ***
Navin, do you have a reproducible test case for this?  I read through all the
dup and have tried to find a reproducible case myself without any luck.  I see a
currently reported reproducible case in bug 137139 for showing Inbox doubling of
messages during compacting, which I haven't seen yet.
It looks like the test case you put in 173399 is one I can use for this bug. 
Using that test case I lost all my msgs in my inbox.  Seems like that test case
could be the one for all the dups too reporting lost msgs during compacting. 
yeah, that one is for sure.
The symptom of doubling the Inbox display, reported in Bug#137139, Comment#6,
still happened tonight on 2002-10-09 build.  Either clear the dupe link there or
re-open this one.
Bug 137139 has been reopened, this bug remains as resolved fixed.  I've tested
this bug in today's trunk 20021011 on winxp and can't reproduce the problem.  
Keywords: dataloss
*** Bug 157018 has been marked as a duplicate of this bug. ***
Plussing for adt.  Need checkin by cob 10/16. Please make sure to get all
required  approvals (drivers) before checkin if this is not already done.
Keywords: adt1.0.2adt1.0.2+
Blocks: blackbird
Comment on attachment 102245 [details] [diff] [review]
proposed fix

a=chofmann for 1.0.2
Attachment #102245 - Flags: approval+
fixed on branch
Keywords: fixed1.0.2
*** Bug 174787 has been marked as a duplicate of this bug. ***
Whiteboard: [ish1+]
Using branch build 20021016 on winxp I tested the scenario in 173399 per
comments 21 & 22.  I also tested various scenarions the include:  
1.) Clicking Compact Folders multiple times while compacting is in progress for
the Inbox = OK, I received the expected message: "The folder "xyz" cannot be
compacted because another operationis in progress.  Please try again later."  I
OK the error and compacting continues without losing msgs or corrupting the msf
file.  
2.) Clicking on Compact Folder multiple times while compacting of Inbox and 2
other  folders is in progress = OK, I received the expected message: "The folder
"xyz" cannot be compacted because another operationis in progress.  Please try
again later."  I OK the error and compaction continues.  I click Compact Folders
again while the compacting is still going on this time in another folder.  I get
the appropriate error msg.  I continue this until I don't get the error msg
anymore and then I check the folders that were compacted.  They are all OK.
3.) Clicking on OK for the automatic compact notice for POP account while POP
Inbox is getting messages.  I get the error notice, OK'ing it.  Result all
folders OK.
4.) Clicking on OK for the automatic compact notice for POP account while IMAP
Inbox is getting messages.  =  OK.

Still need to test on linux and mac before verifying.
Verified on Mac 9.2 and linux using branch build 20021017, changing keyword to
verified1.0.2
Status: RESOLVED → VERIFIED
verifying as fixed since this was tested in the trunk and branch. Note: tested
on trunk build on 10-11 when testing bug 173399.
I want insist on a specific case of this bug, which I reported in a dup of this
bug (bug # 174787). I don't know if this circunstance makes the difference, but
I suffer the folder corruption at same time Mozilla crashed.
I had had some crashes while Mozilla compacts folders, but it never corrupted my
messages (only remaining temporal folders after restart Mozilla, easily deleted).
*** Bug 175980 has been marked as a duplicate of this bug. ***
Whiteboard: [ish1+] → [ish1+][fixedish1]
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.