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!!
Created attachment 102245 [details] [diff] [review] proposed fix We should return not fall through after calling compactNextFolder. major hole... causing real bad bugs.
cc cavin & bienvenu for reviews ? thx.
Status: NEW → ASSIGNED
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.
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
Last Resolved: 17 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. ***
*** 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.
*** 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+
Comment on attachment 102245 [details] [diff] [review] proposed fix a=chofmann for 1.0.2
Attachment #102245 - Flags: approval+
fixed on branch
*** Bug 174787 has been marked as a duplicate of this bug. ***
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
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. ***
You need to log in before you can comment on or make changes to this bug.