[jraph]

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.

[brookst]

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.

[jraph]

> 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.

[jamespo]

Just do a complete rewrite in rust, that will solve all the issues

[goku12]

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].

[1] https://fosstodon.org/@goku12/114077011555069124

[amendegree]

The op is being facetious

[tareqak]

Sometimes, treating a facetious/sarcastic request seriously helps disarm the facetiousness. Other times, it does not.

[amendegree]

English is my first language but I don’t understand this use of “disarm”.

[jraph]

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.

[jraph]

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 :-)

[goku12]

I really can't tell them apart. My fault. But people also get too passionate about it sometimes.

[mattl]

Is whichever part of Mozilla that runs Thunderbird going to rehire the rust team now?

[tomrod]

Honestly? It might.

[dbalatero]

Only by being a statistically different code base, unless you think this is a memory safety bug?

[huimang]

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.

[stefanka]

Safety in rufst is not only about memory safety. It’s also about avoiding unpredictable behavior.

[_bent]

reading through the report, it's not unlikely to be a race condition