Closed Bug 479285 Opened 16 years ago Closed 14 years ago

compact local folder fails because we couldn't remove the .msf file of original folder after compact finished. ForceDBClosed not successfully closing the db?

Categories

(MailNews Core :: Database, defect)

Product:
MailNews Core
Component:
Database
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Thunderbird 3.0b3

People

(Reporter: Bienvenu, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

I'm seeing compaction of some local folders failing because we couldn't remove the .msf file of the original folder after the compaction process is finished. To me, this sounds like ForceDBClosed is not successfully closing the db in some situations. It's possible that the underlying cause is the same as the assertion we see on shutdown about db's left open. This results in nstmp and nstmp-N folders getting left in the folder pane. I'll investigate. This is a pretty visible issue that I think is worth fixing for b2.
Flags: blocking-thunderbird3?
I haven't been able to reproduce this again...I'll keep trying.
Have you examined bug 442588? This plagued me for over 6 months, and then mysteriously disappeared with the last 2.0a3pre build on the 18th...
It would be good to have a more robust way to ForceDBClosed than the current method that only works if we successfully remove all references.
ForceDBClosed could close the underlying mdb to release the .msf file - the danger is that anyone holding onto the db or msg hdrs could crash by accessing freed memory. Maybe there would be a way to get Mork to release the file handle without freeing up all the memory - I'll look into that.
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3
The "failure to compact" is not limited to local folders, I've seen it on server side folders as well. See: https://bugzilla.mozilla.org/show_bug.cgi?id=467305 This can be difficult to reproduce, but from protocol logs, it's clear that Thunderbird is issuing EXPUNGEs, but whatever's cached client-side isn't getting updated. Forcing an index rebuild fixes the problem. As a user, I believe this has to be considered a blocking bug. As someone involved in my organization's email infrastructure, I know that the support call volume this bug will generate are going to be unacceptable.
I haven't seen this again (this bug was about local folder compaction failing, not imap).
I'm going to minus this unless we can figure out a way to reproduce this.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
David, is the regression range close to the date of bug report? Bienvenu in comment #4 > ForceDBClosed could close the underlying mdb to release the .msf file - the > danger is that anyone holding onto the db or msg hdrs could crash by accessing > freed memory. Maybe there would be a way to get Mork to release the file handle > without freeing up all the memory - I'll look into that. does this deserve a separate bug?
I'm not sure of the regression range since I don't compact often - it might have happened earlier as well.
reworking the file handling of mork in that way might be a bit scary, but we could file a bug on it, I guess.
(In reply to comment #0) > This results in nstmp and nstmp-N folders getting left in the folder pane. I couldn't reproduce "left nstmp and nstmp-N" for local mail folder by "outdated msf". (I probably saw it when simultaneous compact & rebuild-index test, but I'm not sure.) Instead, I saw Bug 492344 by test with intentional "outdated msf" condition. David Bienvenu, Bug 492344 is relevant to this bug?
some part of it may be, though it's hard to tell.
External software(auto-backup, file scan by anti-virus software) can interfere "compact folder" by Tb. Putting in dependency tree for meta Bug 498274, for ease of tracking.
Blocks: 498274
bienvenu, still seeing this 2 years later? :) (In reply to comment #0) > I'm seeing compaction of some local folders failing because we couldn't remove > the .msf file of the original folder after the compaction process is finished. > To me, this sounds like ForceDBClosed is not successfully closing the db in > some situations. It's possible that the underlying cause is the same as the > assertion we see on shutdown about db's left open. > > This results in nstmp and nstmp-N folders getting left in the folder pane. I'll > investigate. This is a pretty visible issue that I think is worth fixing for > b2.
Blocks: 324576
I have not seen this in a long time.
(In reply to David :Bienvenu from comment #15) > I have not seen this in a long time. => WFM then. one more nail
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Summary: compact local folder failing for some folders → compact local folder fails because we couldn't remove the .msf file of original folder after compact finished. ForceDBClosed not successfully closing the db?
You need to log in before you can comment on or make changes to this bug.