261–270 of 297 posts
Earlier quoted context omitted.
and then they simultaneously determined "yeah, we might eat your data. Lets not warn anyone about that AT ALL, lets keep the feature activated and let them users lose their data". This behavior ought to be criminal.
It's not criminal, but you're entitled to a full refund of Thunderbird in the event it happens.
Earlier quoted context omitted.
If you've added guards and diagnostics, then you close it until someone else files a follow-up, then it can be re-opened. There's no sense keeping it open unless there are ongoing reports of the issue.
There are users in the comments here reporting the issue affects them. Would some noble purpose be served by closing the existing issue in the hope that they'll complain via more official channels?
Earlier quoted context omitted.
See, you don't understand. Fixing the bug before reproducing it would violate the process .
How do you fix a bug you can't reproduce? It's a genuine question because I'm puzzled here. A very small number of users have this bug (and tbf, it's a really bad bug), and are unable to consistently reproduce it and it seems none of the developers have been able to (the seemingly random nature of the bug occurring is not helping). How is it supposed to be fixed?
- You can extend logging to gather additional information to reproduce it.
- You can try to reason about the code and figure out possible causes.
- You can attempt to formally verify the correctness of the code.
- You can put guards into the code against unexpected states and actions.
- You can verify the correct result of previous actions before any destructive actions.
- If all fails you can scrap the piece of code in question since it seems to be beyond your ability to maintain.
Earlier quoted context omitted.
I would not want my email client to be relying on such brittle and incorrect heuristics. A better workaround would be to keep deleted emails around for some time so users have the option to restore them if the bug triggers. But this has drawbacks such as potential privacy breakage (you meant to delete mails you don't want the chance that anybody sees it) or free disk space management (your local drive is overloaded a…
Well, would you rather have a brittle heuristic lose all of your mail? My point wasn’t that this is a great solution, just that it is very easy and almost certainly better than doing nothing for almost two decades.
That's not what's happening. I wouldn't expect such an heuristic to be currently present. There is a bug, not something intentional.
> almost certainly better than doing nothing
No, because with such an heuristic, you add behavior that's difficult for the user to understand well and to work with. With such an heuristic, you will lose some mails and at some point the process stops in the middle. Which mails have you lost? What is "many" mails? 10? 100? What if my computer is fast and is deleting 100s of mails per seconds, losing all the mails anyway? What if it is slow and never triggers the heuristic?
If the heuristic does trigger, you end up with a mixed situation where you still have lost some stuff, but not all, and it'll be impossible to understand which ones. It doesn't fix the issue (you still lose email), just makes it even more difficult to understand even for the devs when they inevitable need to track down related issues. You really don't want to willingly add mechanisms that feel like they are non-deterministic: they are hard to debug, and hard for the users to grasp.
A way better solution is backups anyway: if you care not to lose your emails, you should be backing them up. From the beginning, your local TB mails are not a proper backup of your IMAP account because it's two-way synchronized so you need a backup somewhere else.
A still better workaround is disabling the move to local folder feature and make people copy and then manually delete mails.
Not saying your heuristic is not a good idea or clever (it is clever and could lead to further good ideas), just that after reflection, it should probably not be implemented. It barely starts to address the issue and adds complexity for everyone involved.
Earlier quoted context omitted.
It's like a car whose engine randomly shuts down with a very low reproduction rate. Except with cars when this happened GM has recalled 30 million cars and paid billions of fines. Emails to email client is an engine to the car. It is pointless without one and it is THE purpose of it. All the rest of functionality like fancy UI, filter, notifications, editor is meaningless if your emails were deleted without recovery.…
The big difference is a car with an engine that randomly shuts down is a life-and-limb safety issue. An email client that corrupts the database is extremely unlikely to cause a loss of life, even if the consequences are costly. That said, even if the bug is impossible to isolate, it sounds like the chain of events that leads to it is known. They probably should disable the feature until someone is motivated to fix or…
Earlier quoted context omitted.
Note that this is why you use copy, check, then delete, instead of just "move" data, whenever it's important that the process works correctly Even if the software doesn't have known bugs, I do it if the data is important enough and especially if I were to not have a backup (for example, because the storage provider takes care of backups and redundancy. I personally like to have another copy that I manage myself, but…
No. The bug happens with copying.
Earlier quoted context omitted.
It happens to me regularly. You can fix it by redownloading the message from the server using the "repair folder" feature, and I have backup, but it IS infuriating. I have no good alternative to thunderbird, it does so much of what I want. But this bug is awful.
I have been using TB on all operating systems with 8 or 9 users since 2006 and I never even once encountered this issue. As a software developer fixing stuff like this is only possible if you can reproduce it or otherwise get logs, telemetry and similar things, otherwise it is pretty much just guesswork. Granted given the severity of the consequences I would've chosen a more defensive move-strategy (e.g. one that del…
As a software developer you should be able to reason about your code and work backwards from the observed result to investigate possible causes.
When a plane crashes or bridge collapses the engineers tasked with finding the cause don't just throw up their hands if they can't make it happen again.
Earlier quoted context omitted.
There are users in the comments here reporting the issue affects them. Would some noble purpose be served by closing the existing issue in the hope that they'll complain via more official channels?
Have the been any potential fixes made since those reports?
I wanted to love Thunderbird, used it for years then a bug [0] literally deleted all my emails. I regularly see updates of people understandably raging on the ticket :( It's a bug that literally deletes user data from both the server and the client without warning. It's been open and confirmed for 17 years straight. It could happen to you. How is it not top 1 priority to fix it? [0] https://bugzilla.mozilla.org/show_…
It's amazing that thread seemed to take 5 years before someone mentioned their IMAP server and basic configuration info.
Earlier quoted context omitted.
The two search boxes is bizarre. It feels like two rival programmers each wrote a half-baked search feature and rather than management telling them "Unify your two approaches", instead they said "Just throw them both in there and let the user figure out which one they want."
There aren't two search boxes. There is a search box in/below the titlebar and a filter for the current folder.