Closed Bug 1791354 Opened 3 years ago Closed 4 days ago

Compact repeats, with invalid savings size

Categories

(MailNews Core :: Database, defect)

Thunderbird 102
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gherlt, Unassigned)

References

()

Details

(Whiteboard: [closeme 2026-04-01])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

I start thunderbird, automatic compression of accounts folders starts.
In the last weeks it does so again and again, the freed up space is always the same.
When I do compress just one folder (in my case yahoo pop3), it says 21.9 MB freed up.
and 30s later he does the same, and 1 day after it is the same.

Actual results:

So TB seems to see the need to compress, proceeds, but does not store the result.

Expected results:

store the resulting now compressed folder and not compress again

Severity: -- → S3
Component: Untriaged → Database
Product: Thunderbird → MailNews Core

There is no compression in Thunderbird. There is however a compact function.

See Also: → 1260698
Summary: Thunderbird compresses same folders again and again, "gain" is same each time → Compact repeats, with invalid savings size

I am seeing the same behavior as of earlier this week. I have TB 102.5.1 set to compact at 100 MB (same setting as always) and I don't allow TB to compact automatically, so I get the "Thunderbird needs to do regular file maintenance to improve the performance...." pop up each time.

Since yesterday, every few hours(?) or when I restart I am asked to compact. When I agree, the compaction seems to happen, ending with the message "Done compacting (approx. 124 MB saved)." But if I restart TB, I am immediately asked to compact again. Same amount of space to be saved: 124 MB.

Interestingly, in the middle of all this, I did some cleanup, deleting or moving about 150 e-mails, and that time the amount to be saved jumped to 155 MB. But it's now reverted to 124 MB.

The error console is full of messages like this:

gloda.index_msg: Observed header that claims to be gloda indexed but that gloda has never heard of during compaction. In folder: mailbox://mgoldey%40domain.net@pop.domain.com/Sent sketchy key: 4273563457 subject: Final reminder -- XXXXXXXXXXXXX

If this sounds familiar, it's because it's the same message in the bug I've been reporting on for about 8 years: https://bugzilla.mozilla.org/show_bug.cgi?id=520115

Since I wrote comment 2, the compaction pop up window has appeared six times. Same message, same size, compacting doesn't change anything.

Immediately after I wrote comment 3, I deleted a single e-mail and was asked to compact again. The error console is full of those "sketchy key" errors which seem to repeat each time I compact. That is, the same 30-odd messages are referenced in the gloda.index messages.

If I had to pick an event that started this problem, it would have been deleting an e-mail with an 80 MB attachment. But that may have been coincidence.

See Also: → 1783547

mgoldey, are you still seeing this issue?

Flags: needinfo?(gherlt)
Whiteboard: [closeme 2026-04-01]

No, I have not seen this behavior in a long while. I still compact manually and the threshold is 100MB. For quite some time now, I get popups requesting compaction every few weeks, instead of constantly, and they never recur immediately.

I would assume this problem has resolved itself.

Thanks for the update

Status: UNCONFIRMED → RESOLVED
Closed: 4 days ago
Flags: needinfo?(gherlt)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.