Open Bug 1556639 Opened 5 years ago Updated 3 years ago

email disappeared/lost while compacting

Categories

(Thunderbird :: Folder and Message Lists, defect)

defect
Not set
critical

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: bugzilla.tb, Unassigned)

References

Details

(Keywords: dataloss, Whiteboard: [dupeme?])

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

Steps to reproduce:

I found similar issues, but most years old or incomplete or much older version.

  • I have a POP3 mailbox
  • emails are fetched every 10 minutes
  • but only headers
  • this is not the main Thunderbird instance, only to recognize important emails
  • When I checked the inbox, there were about 10 new emails.
  • I selected a block of 5 emails to delete.
  • After delete I'm asked to compact the inbox.
  • I agreed to compacting.
  • While compacting I clicked on 'download the rest of the message' on the next new email I'm interested in.

Actual results:

When compacting has finished, the new email with downloaded content has disappeared.

I searched for the disappeared email and found it!
The email is in search results, with correct subject, date, sender and recipient addresses.
But when I click on the email in search results, I got an empty list again.

Expected results:

The new email, for which I downloaded the content, should be shown in the inbox message list.

Well, in general it's not a good idea to interfere with the compaction while it is running. Of course it shouldn't cause issues like this one.

What happens when you repair the folder? Right-click, Properties, Repair Folder.

I fully agree, that this was a bad idea, but shit happens ;-)
After repair I have a bunch of duplicated and already deleted messages in the inbox. The repaired messages had no filters applied, so it was easy to detect and delete them again.
But the email in question is gone. It is still listed in search results, but not in the message list and I can't open it from search results.
This is no big issue for me yet, I have this email still on the server and another Thunderbird instance, but it may be an essential issue for somebody else.

Maybe this is somehow related with other observations I made when I was hit by 7 years old Bug #750630, which is still present in 60.7.0.
When the rest of the message is downloaded, a duplicate of the message flashed in the list.
I assume a new message with downloaded content is inserted in the list and the header only message is removed then. Looks like this transaction is interrupted somehow.

Whiteboard: [dupeme?]

Changing the summary so I can find it better later on "compact lost".

Summary: email disappeared while compacting → email disappeared/lost while compacting

It seems we failed to put the correct severity and keyword so this has the properly visibility

Severity: normal → critical
Keywords: dataloss

Artem, does this still reproduce for you?

Flags: needinfo?(artem.semenov)

I can't say how things are now with this issue. I avoid this kind of action from the moment an important email was lost because of this. But I know that the Thunderbird data storage subsystem contains a sufficient number of bugs.

Some of them are very annoying:

  1. Sometimes (but quite often), immediately after the start of the program or after several hours of work, but in the absence of active actions with a specific folder, index files for this folder (Inbox and its subfolders) for some reason become invalid. Because of this, the message filtering rules cannot place the message in the specified subfolder and place it in the root (Inbox). When I select this folder in the folder tree, the status bar displays a message like "Creating an index file for the folder <DirectoryName>...".

  2. Sometimes (but quite often), immediately after the start of the program or after executing the "Repair folder" command (!!!), a lot of emails already deleted or filtered/moved to other subfolders appear in the Inbox folder. These emails are in the "Header only loaded" state. Neither compressing the folder nor executing the "Repair folder" command helps to get rid of these "dead" emails. There is only one way - to get some new email from the server. Therefore, I have to send myself an empty letter and then receive it. It's very infuriating.

Perhaps, on the upcoming holidays, I will still risk diving into the code and try to find out the reason. But there is such a awful mixture of C++ and JS code that debugging is an order of magnitude more difficult than if it were just C++.

My current version of Thunderbird is 78.14.0 (debian 10).

Flags: needinfo?(artem.semenov)
You need to log in before you can comment on or make changes to this bug.