Bug#321102: more ways to reproduce this bug
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
Reply to: