[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    [Bug 104956] dimap: sudden mail loss
From:       Pierre Habouzit <madcoder () debian ! org>
Date:       2006-06-28 17:22:40
Message-ID: 20060628172240.29966.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=104956         




------- Additional Comments From madcoder debian org  2006-06-28 19:22 -------
I've rethought a bit, and here is IMHO the explanation for the many instances of the \
dimap mail loss bug (that I really think is not in one but many places).

dimap is stateful, and kmail then has to trust a set of file to track what is already \
synced and what needs to. Those files are critical, because *any* corruption has to \
be noticed, and in case of corruption you have to fall back to the previous state.

When I tried to make kmail loose mails (in #71) I expected it to crash, or to say \
"internal error" because he can't write/read the uidcache file. which it didn't. so \
what has to be done is (IMHO):

(1) list all the files responsible for the statefulness of dimap in kmail (uidcache \
is part of them) ; (2) track all uses of those files in the kmail source code, and \
CATCH THE DAMN ERRORS, and in case of errors, fail loudly.

If it happens to do things like:

a. begin transaction (read uidcache)
b. do a lot of things with our local cache of mails
c. end transaction (write uidcache) <--- fails here *bang*

then kmail should try hard to fall back to the state of (a)

Moreover if kmail craches during (b), it must have a way to tell he was in the middle \
of a transaction. A way could be to write in the uidcache (or like I already \
suggested to create a new file, but one more is maybe one too much ;p) that kmail is \
starting a transaction. When you restart a transaction, and that it already says that \
a transaction is started, then you are recovering from a previous crash, and you MUST \
HANDLE IT WITH GREAT CARE.



What I proved with my way to reproduce the bug is that kmail trusts files that it \
does not deals with with enough care. so it trusts crap, and no surprise it breaks \
from time to time.


and since kmail design of implicit deletion is fragile, (like kmail developers \
already aknowleged it) that quite big flaw of handling of index files, becomes a \
terrible catastrophe. _______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel


[prev in list] [next in list] [prev in thread] [next in thread]