Advise: Before you end up with corrupted files, I would offer this advise. I'm not sure of you have alot of emails kept only in the Inbox folder, but it sounds like you do. Create some new folders and organise emails for storage. eg: Family, friends, Company name, Online orders, Bills, Archive by year etc. After all, an Inbox is an Inbox for new incoming and unsorted mail, not an archive folder. It is also less risky to spread emails over various folders. If your emails are important then seriously consider organising as advised and recommend you make sure have a backup, after all, imap folders and server folders are in effect one and the same and only one copy is risky.

When you delete or move an email, it gets 'marked as deleted' and hidden from view. So folders like Inbox, Drafts, Junk would expect to need compacting on a more regular basis. When you compact those 'marked as deleted' emails are fully removed to create space and tidy the mbox files. It is possible you have moved some emails, so TB would detect a saving of space in a file eg: Inbox, however as you moved to another folder, you are not saving space in general terms. This is a possible reason.

A complete copy of file has to be created prior to compacting, so large files may take a long time. After creating new folders and sorting emails, you may find it is a quicker process and less risky.

The incorrectly reported size is a rare bug that doesn't have a solid diagnosis. But any information you can provide may be interesting.

Thanks for the responses.

I am happy to provide information to help assessing this bug. What would you like to know?

Thanks for the general comments, @Toad-Hall; indead I am using large inbox folders. However, as far as I know, this can hardly be managed elsewise with Google-based accounts. If I am informed well, Google does not really have separate folders but just tags. Ninetheless, I have once tried to move all emails older than 1 year to another folder, and it did not help a lot.

I do not want to have to sort emails manually, and I like to see all new emails at once. Though I understand that having things in order is my responsibility, I think Thunderbird should support me in this rather than me changing my behaviour for the sake of Thunderbird. After all, this is the reason why I am using Thunderbird.

Note that I usually never delete emails manually and that I only keep local copies of a small fraction of emails. I want to have everything in the cloud, and I think this also reduces the need for a regular backup.

samufi said

Note that I usually never delete emails manually and that I only keep local copies of a small fraction of emails. I want to have everything in the cloud, and I think this also reduces the need for a regular backup.

Just perhaps your desire to keep a "small fraction" locally is part of your problem. How do you manage that process?

Have you de-selected the option to keep messages in all folders for this account on this computer? in the Synchronization and storage settings for the account.

Have you set the only synchronize the last XX days setting?

I have selected to keep local copies, but I am indeed only downloading emails from the last year. How could that affect the issue? I understand that every day a couple old emails may need to be "deleted" (because they do not need to be stored anymore), but this should still not lead to such huge overestimates, should it?

samufi said

I am happy to provide information to help assessing this bug. What would you like to know?

In regard to the amount of freed space, unless you stumble on useful information yourself, it's not currently something we (or at least I) have time to help the develop information. Too many higher priorities. Thanks for the offer.

Okay, I understand that. To see whether I have any helpful information, I might have a look into the code myself. Would you be able to assist me just by pointing me towards the file with the routine where the freed-up space is computed? A search of the whole code brought me to source/comm/mailnews/base/src/nsMsgFolderCompactor.cpp, but I did not find a function computing the new size there.

Btw, regarding the rareness of the problem: I am not sure how many people would ever notice (and then also report) this bug, as it manifests in weakened performance only. I find it well possible that many users may not be aware of how well Thunderbird could work without this issue.

There appears to be two bugs related to this topic.

https://bugzilla.mozilla.org/show_bug.cgi?id=1434864 This is just about the savings shown in the status bar. I did not read it all as it does not look a likely candidate.

https://bugzilla.mozilla.org/show_bug.cgi?id=1260698 This is about the actual figured reported and by extension expected. This looks like what you are talking about here. It goes into some detail on the issue including having a proposed patch that has not moved forward. Again I did not read it all, but it is probably the starting point you are looking for as it discusses the relevant code.

Exactly. And aceman is the guy to assist you.

The tool to search Thunderbird source code is https://searchfox.org/comm-central/source https://searchfox.org/ describes the query language

Thanks for helping!