On 28 Jul 2012, at 16:28, Joachim Tingvold wrote: >> Understandable. It seems like a lot of work for a small problem, but >> the problem is that when MailMate detects an unexpected state of the >> local cache/database (there are numerous checks in the code for >> unexpected states) then there is no way to know exactly what the >> problem is. If MailMate ignores the problem or tries to fix it >> without knowing exactly what happened is too dangerous. It could >> escalate the problem to a more serious state with the risk of leading >> to data loss. > > I see. Is there a difference between this scenario, and the scenario > where you move emails between folders on another client while MM is > running? Wouldn't that be the same, more or less?
No, that would be really bad :-) MailMate is designed for IMAP and has been tested (and stress-tested) with messages being moved around and flags changed. The worst thing that can happen is that messages are duplicated (if moved simultaneously in two email clients), but that is not a problem with MailMate. It is just part of how IMAP works. (Often that kind of testing reveals bugs in IMAP servers.) The bug in MailMate is related to a message being moved from, e.g., INBOX to Inbox. This works fine until the change is reflected on disk (happens in a separate thread in MailMate handling all disk i/o) where the message is moved from, e.g., `.../INBOX/Messages/42.eml` to `.../Inbox/Messages/42.eml`. Unfortunately those two locations are the same on disk and the code aborts because of some unexpected result (I haven't looked into the details yet). When MailMate is restarted it rolls back the database to a safe state, but this apparently fails because of the nature of the bug (it cannot move the message back) and this is where you are requested to rebuild the database. I hope that makes a bit more sense. -- Kind regards, Benny