On Monday 15 January 2007 06:45, Bastian Venthur wrote: > One last word about this bug: Bugs like this will always be reproducible > until two-part actions like move mail from a to b (= copy mail from a to > b, delete mail from a) are not handled somewhat atomic. In the current > implementation KMail does not even try to do stuff like this atomic. If > you fix this, then I think you will fix the bug. > > Summary: I've presented altogether five ways how certain situations in > KMail can lead to data loss. I even was able to lose data by just > justing CTRL-L like upstream suggests. > > All my examples might seem minimalistic and somewhat artificial, but > please keep in mind that this is just in order to make the bug easy to > reproduce! It's not hard to imagine how situations like this can happen > to an average user on a more complicated setup. Thank you, Bastian, for writing that. I think that is the best explanation I've seen so far. I'm not sure if doing dIMAP atomically would make sense; that sounds like regular, online IMAP to me. The whole point of dIMAP is to make changes offline and then sync them all at once. (Although the reason I use dIMAP is merely to keep an offline copy of my IMAP mail for backup. I would love a hybrid IMAP mode that would keep a local copy of all messages, and make changes live on the server as you make them when you are online, but queue changes for later syncing when you're in offline mode [and KMail even has an "offline mode" option]). I think a good workaround would be for KMail to keep track of whether it has unsynced changes, and warn the user if he tries to close KMail or log out before syncing the changes. It would also be nice if the connection timeout/retry code was made more robust to cope better with times where the server or connection to it goes down. Just yesterday I had some timeouts while uploading a large message to the server after moving it from one folder to another (why can't it just tell the server to move the message, rather than uploading it again?), and the process didn't finish until I stopped and resynced a couple of times, because KMail didn't timeout and retry on its own. Perhaps the real solution is to get rid of a separate disconnected/offline IMAP mode and make a single, hybrid IMAP mode. When you're online, it should make changes on the server as you make them locally. When you're offline, it should queue changes for later syncing, and warn the user if he quits or logs out without syncing them. And whether you're online or offline, it should have an option to keep local copies of all messages.
Attachment:
pgpMp8ObV0cGo.pgp
Description: PGP signature