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

RESOLVED WORKSFORME

Status

MailNews Core
Database
RESOLVED WORKSFORME
9 years ago
7 years ago

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Tracking

(Blocks: 2 bugs, {regression})

Trunk
Thunderbird 3.0b3
x86
Windows XP
regression
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

9 years ago
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?
(Assignee)

Comment 1

9 years ago
I haven't been able to reproduce this again...I'll keep trying.

Comment 2

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

Comment 3

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

Comment 4

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

Updated

9 years ago
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0b3

Comment 5

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

Comment 6

9 years ago
I haven't seen this again (this bug was about local folder compaction failing, not imap).
(Assignee)

Comment 7

9 years ago
I'm going to minus this unless we can figure out a way to reproduce this.
Flags: blocking-thunderbird3? → blocking-thunderbird3-

Comment 8

9 years ago
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?
(Assignee)

Comment 9

9 years ago
I'm not sure of the regression range since I don't compact often - it might have happened earlier as well.
(Assignee)

Comment 10

9 years ago
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?
(Assignee)

Comment 12

9 years ago
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

Comment 14

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

Comment 15

7 years ago
I have not seen this in a long time.

Comment 16

7 years ago
(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
Last Resolved: 7 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.