data loss bug: Inbox re-fills with deleted messages, which risks deleting wrong messages
I've observed this behavior a few times in the last few days, although I can't pinpoint exactly when it started (in particular, I'm on version 60.0 but I'm not sure if it started with this one):
I have a bunch of new messages in my inbox. I delete them quickly as usual by hitting the Delete key.
Then, a few seconds later (even if I am still in the process of deleting messages), the inbox "refreshes" and the messages that I deleted are suddenly there again. But then, even if I stop touching the keyboard, the messages disappear one by one, in (I think) the order that I deleted them the first time.
The reason this is a potential data loss bug is because I'm normally eyeballing the messages in my inbox and pressing "delete" several times in a row, and skipping past the ones I want to keep. If messages are randomly re-appearing in the list after they've been deleted, then the results of hitting the "delete" key multiple times become unpredictable, and I run the risk of deleting a message that I actually want to keep.
Has anyone else observed this? Is the only workaround to just keep an eye open to see if Thunderbird is "reviving" messages that were deleted a few seconds ago, and then stop interacting with the program until it catches up with me?
Tutte le risposte (2)
I would suggest a principal workaround would be to eliminate your anti virus product from scanning incoming mail, the Thunderbird profile folder and most importantly of all remove any add-ons it installs in Thunderbird.
Delayed updating from the server is often a byproduct of the 10 or 20 performance tax anti virus products levy.
I don't have any extra anti-virus software and in any case nothing where the settings have changed recently, and I don't have any add-ons or plug-ins enabled.
Regardless, even if the updating from the server were "delayed", that should not cause already-deleted messages to reappear after they have been deleted. The correct sequence should be: 1) User hits delete key to delete a message in the inbox 2) The client deletes the message locally and updates the UI to remove the message 3) The client asynchronously sends a request to the server to delete the message 4) If, while waiting for step #3 to be completed, the client receives an updated listing from the inbox on the server and it sees a message that has already been deleted in #3, it should not remember that the message has already been deleted on the client side and should not display it. Eventually the async delete request in #3 should go through and then the next time the inbox is refreshed it will not contain that message. (Or, if the delete request in #3 does *not* go through, then the delete failed, and it *is* the correct behavior for Thunderbird to display the message again. But that's not what's happening in my case, because the delete requests are going through successfully and the messages do disappear eventually.)
(Apparently, Thunderbird was doing this correctly until some time recently, because I never previously saw deleted messages being brought back to life before.)
So if step if #3 or #4 is "delayed" -- whether because of anti-virus or slow network or anything else -- then it still shouldn't cause deleted messages to re-appear, if the steps are implemented correctly.