Closed Bug 173357 Opened 22 years ago Closed 22 years ago

Compacting folders when getting lock failed

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: naving, Assigned: naving)

References

Details

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

Attachments

(1 file)

proposed fix
639 bytes, patch
cavin
: review+
Bienvenu
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
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 fix — — Splinter 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: 22 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.2 → adt1.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
Keywords: fixed1.0.2 → 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.

Attachment

General

Creator:
Created:
Updated:
Size: