if (!user_requested_mass_delete && delete_requests_past_second > 10) throw(“we sure seem to be deleting a lot of stuff from the server”)
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.
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.
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].
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.
No, you disarm the facetiousness, the same way you'd disarm a trap. Disarming the person wouldn't make sense.
https://en.wiktionary.org/wiki/disarm
> 2. (transitive) To deprive of the means or the disposition to harm; to render harmless or innocuous.
> [quotations] to disarm a man's wrath
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? =)