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

List:       kmail-devel
Subject:    [Bug 104956] dimap: sudden mail loss
From:       Rob Kaper <webmaster () horrorpops ! com>
Date:       2006-06-28 20:16:30
Message-ID: 20060628201630.9076.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 webmaster horrorpops com  2006-06-28 22:16 -------
Anyone who next experiences this bug please check whether all data is still present \
locally (and if so, back up) before starting KMail/Kontact again. Perhaps check the \
IMAP account with a different client, not supporting DIMAP.

I've checked the IMAP RFC a few times and I think the loss of data does not occur \
before or during the crash but when KMail starts again with an incomplete index and \
then starts deleting/expunging all messages it doesn't know about. In the IMAP \
protocol messages are marked for deletion and then expunged. Clients should not \
obviously not remove actual data until explicitly receiving the expunge responses per \
message and servers should not expunge messages not explicitly communicated to be. \
Neither would make sense to happen for to-be-kept messages during synchronisation \
even in the case of a crash and/or network failure. However Kmail expunging the \
messages (and only then delete them locally upon success) starting with an incomplete \
index would cause the deletion.

If not useful for locating the bug, checking the actual state of the data locally and \
on the server might prevent data loss for users experiencing it, or enable them to \
backup and restore.

I cannot explain this problem at all unless at some point KMail trusts a list of \
messages to be kept (presumably the index) instead of a list of messages to be \
deleted and then imposes that trust on the server.  I recommend someone check if this \
could indeed occur and then make sure DIMAP only relies on an explicit deletion list \
instead. This might turn out to be a large change, but from a design perspective \
anything else means asking for problems.

(I swear, if I find the time I'll just have to get back to KDE development.)
_______________________________________________
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]