found 321102 4:3.5.5.dfsg.1-5 thanks
Hi, One major argument against my previous two attempts to reproduce this bug is, that I'm abusing KMails functions. F5 and "rebuild IMAP cache" do exactly what they're supposed to do and it's not KMails fault if the user loses mails when (ab)using this features. I understand this point of view although I still disagree. But in oder to protect our users I reproduced this bug again. This time by using KMail "correctly". Setup: This time I'm using two different accounts "foo" and "bar" and move a mail from one account to the other. (3) Delete mails by checking only one Account: - Move a mail from foo's inbox to bar's inbox No changes have yet been committed on the serverside - now click "check mail in foo" (and only in foo) KMail now removes the mail from foo's inbox but does not copy it into bar's inbox. - Close KMail Check the mails on the serverside: one Mail is lost and it will be lost until you restart this particular instance of KMail which can be in a few minutes, days or never. KMail leaves the state on the server in a broken state. Checking your mail from another machine will look like you've just lost a mail. Maybe the user will now use KMails "rescue" operations (F5 or rebuild the cache) and therefor worsen the situation. If the user cannot start KMail on the first machine for some reasons, it's mail will be lost forever. (4) Delete mails by checking mail automatically: You can even lose mails by don't doing anything. This chance is always present when KMail does not check all available accounts together. Eg. When you set "check mail automatically every x minutes" on account foo and set "check mail automatically every y minutes" on account bar where x < y then you're actually doing the same as in Example (3) just automatically: - Move a mail from foo's inbox to bar's inbox No changes have yet been committed on the serverside - Wait x minutes until KMail checks foo's mail KMail now removes the mail from foo's inbox but does not copy it into bar's inbox (until y minutes when KMail checks bar's mail) - close KMail before it checked bar's mail, Check the mails on the serverside: one Mail is lost and it will be lost until you restart this particular instance of KMail which can be in a few minutes, days or never. Since I can already hear someone saying: "Oh, you're abusing KMail again, just use CTRL-L to check all accounts as you're supposed to do!", here is my hopefully last part: (5) Lose mails by unavailability of one server: - Move a mail from foo's inbox to bar's inbox No changes have yet been committed on the serverside - Disconnect server bar (eg shutting bar's IMAP server down), to simulate a broken connection to *one* of the two servers. - Press CTRL-L (check all accounts -- the "right" way) KMail now removes the mail from foo's inbox but does not copy it into bar's inbox since bar's server is unavailable. It gives a warning that the server is not available but does not mention that an pending operation is currently broken. - Close KMail Check the mails on the serverside: one Mail is lost and it will be lost until you restart this particular instance of KMail which can be in a few minutes, days or never. If KMail would copy from foo to bar and only delete the mail on foo if the copy was successful, that this mail lost could have been prevented. 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. Cheers, Bastian -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]