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 and you want to urgently free up space) or ux confusion (this is a de facto trash but Thunderbird already has such a feature)
Ultimately, what needs to be done is make the code robust, make sure there are no race conditions, etc.
> Well, would you rather have a brittle heuristic lose all of your mail?
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.
Except the bug was filed in 2008. Back then, Rust was Graydon Hoare's personal project that Mozilla wouldn't start funding until a year later. Rust was written in OCaml and the famed borrow checker wouldn't be in place until 2010. The first public release was v0.1 in 2012 and the first stable release 1.0 wouldn't happen till 2015. The language was very different back then with sigils, garbage collection and green threading as language features. So this bug was already bugging people when Rust was just an embryo that was still years away from birth.
Now even if we neglect the timeline, Rust only guarantees memory safety. If TB is deleting mails on the server too, then the corruption is happening over IMAP connections as well. Does that sound like a memory safety bug to you? Perhaps it is. But how do we eliminate the possibility of a logical bug that Rust won't protect you against, when nobody has any clue even now? And all that aside, if you're going to rewrite it in Rust, you might as well start a new project in Rust instead of porting an old design that may potentially contain a language-agnostic logical Heisenbug.
I'm not trying to be hostile here. I started using Rust in 2013 (I have 12 years of experience in a 10 year old language, and a bunch of repos that I can't compile anymore unless I compile the compiler from old commits somehow!). I wouldn't use C or C++ for any of these applications - I simply don't have enough competence to avoid the kind of bugs that Rust protects me from (despite being a hardware engineer with more knowledge about memory management than about type system theory). Despite all that, statements like this will only cause an unwanted backlash against Rust. Not that you're entirely wrong, but some people are so offended by such suggestions for reasons that are still under investigation, that they start a crusade against Rust [1].
You counter the facetiousness in a way it stops spreading and possibly even spark a constructive discussion is how I understand it (ESL though). I certainly observed this phenomenon myself (although as the person being facetious, I often feel like "I was joking, I actually agree, that's indeed what I was actually implying, but good you made it clear and explicit I guess")
I guess you'd disarm the person being facecious rather than the facetiousness, like you'd disarm someone about to cast you a magic spell.
At this point, answering to a "rewrite it in Rust" comment which doesn't go into details is a cultural faux pas, you just smile or roll your eyes and move on :-)
Looking at the various issues reported in this thread, it honestly seems that burning the entire codebase and rewriting it would be the best choice. Bonus points for using a modern systems programming language.
A better approach might be to feed all of this into an LLM to have it figure it out. If it finds a bug and has a fix, reproducing it might be easier and a test could potentially be written.
I don’t think LLMs are the answer to everything, but this would be a good test for newer generations of LLMs as they’re developed.
Worst case- it deletes all of your emails, but that would’ve happen anyway, right? =)
