Bug#321102: a way to reproduce KMail/DIMAP data loss
reopen 321102
tags 321102 - fixed-upstream
thanks
Here are some minimalistic ways to reproduce this bug.
Some observations:
1) KMail does not show what's on the server but rather what should be on
the server:
When moving mails around in KMail, the mails aren't actually moved on
the server directly. KMail does this later (when?). Even when you close
and reopen KMail the mail is not moved on the server, although KMail
pretends that it has moved the mail! (Which is the root of the problem
as we will see later)
2) Pressing F5 inside a folder commits open changes for this folder on
the server.
2.a) Pressing F5 inside folder foo commits changes for foo but not for
folder bar (which is so dangerous that I cannot believe this was
actually implemented)
3) Rebuilding cache (sorry translated from my German version) seems to
re-read all the data from the server and overwrites KMails yet
uncommitted actions -- for this folder!
4) People who use IMAP tend to check their mails from more than one machine.
5) People have more than one account and sometimes move files from one
folder to another one on a different account.
Here is what I've used:
- Current KMail 1.9.5 from Sid
- current Dovecot from etch on the server side
- Initial layout: Four mails in inbox and two empty folders:
|-- Inbox
| |-- mail 1
| |-- mail 2
| |-- mail 3
| `-- mail 4
|-- folder 1
`-- folder 2
Ok let's get to the bug. I found different methods to reproduce this
bug. Here is the first and simplest method: I'll delete a mail by moving
a mail from one folder to another:
1) Drag mail 1 to folder 1 (move).
2) Now take a look on the server: Inbox has still 4 mails, folder 1 is
still empty. The changes are not committed to the server although KMail
pretends to.
3) Now go into your inbox and press F5 (refresh)
4) On the serverside mail 1 is now deleted from your Inbox but still not
present in folder 1. In other words if you'd close KMail now and delete
all it's configuration files from this box, mail 1 is lost!
Of course mail 1 is still living somewhere in KMails config files an
pressing F5 folder 1 will bring it back, but only on this machine.
Checking your mail from another box, it will look like your mail just
disappeared. Which is actually true since it is not on the server anymore.
Think this scenario is unrealistic? I for one often move a mail from my
inbox to another folder. And even more often press F5 in my inbox to
fetch new mail.
Here a second way, even funnier:
1) Move mail 1 (by dragging) from folder 1 to folder 2
The changes are not yet committed on the server! But KMail pretends to.
2) Rebuild cache on folder 2 (KMail will delete the just moved mail from
this folder since it's not present on server)
3) Refresh folder 1 with F5. KMail will remove the mail from the server
(which was not visible inside KMail)
Now you have effectively deleted mail mail 1 from KMail and the Server.
I'm sure there are many other ways to exploit this behavior. I've not
seen a single waring or error from KMail it just did what I say and
happily removed mail precious mails. I found another way to lose mails
in combination with two different boxes using the same account and
moving mail, and (ab)using F5 and rebuilding the cache. But I forgot to
write the steps down and am to lazy now to try to reproduce it again.
I even found a bug where KMail duplicates mails which is relevant to
this bug since it's the same problem.
I've not yet played with different boxes sharing the same account (home,
work) or one box having two accounts (and moving mails), but I hope my
setup inspired a few people to do some testing themselves. Please let me
know if you need some help or further information.
So please urge to upstream to reopen it's relevant bugreport(s) (or
better to fix them), I don't have the nerve to deal with upstreams BTS.
And for Debian: please disable DIMAP completely or remove KMail from etch.
Cheers,
Bastian
--
Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
Reply to: