[Kde-pim] Mail loss when moving email while it is downloaded

Volker Krause vkrause at kde.org
Sat Feb 11 12:18:28 GMT 2012


On Sunday 05 February 2012 20:28:11 Andras Mantia wrote:
> Sven Burmeister wrote:
> > Hey everybody!
> > 
> > This is reproducible with akonadi 1.7.0 and kdepim 4.8.
> > 
> > 1. Use an imap account with a local trash folder and a slow internet
> > connection (or make the attachment bigger).
> > 2. Send yourself an email with a large attachment, i.e. large enough that
> > it takes a minute to download.
> > 3. click on the email in your imap inbox (preview pane switches to
> > "downloading") and press DEL immediately, i.e. delete it while it is
> > downloaded
> > 4. click on a few other emails and delete (move to trash) them  as well.
> > They will not be moved instantly but kmail "waits" for the first one to
> > finish downloading.
> > 
> > Bug 1 (annoying): The preview pane stays at "downloading" although the
> > user has already clicked away from the message that was started to
> > download, i.e. kmail should show the other emails while downloading the
> > first one in background.
> > 
> > Bug  2 (mail loss): Wait until kmail finished moving all emails, i.e. they
> > are not shown greyed-out in the message list but gone from it. Switch to
> > the local trash and click on the email with the large attachment. Here
> > only the headers are shown and the email's content is gone, i.e. no
> > attachment.
> > 
> > If you know why this is happening please let me know the details. I'd like
> > to understand more about the cache/download/move logic used since I think
> > there is another issue that causes mail loss if data is moved due to it
> > not being downloaded before moved, e.g. emails in an imap folder that get
> > moved after x weeks by the "expire settings for this folder".
> 
> What you found is interesting. I can imagine that when you delete/move to
> trash, the item is moved in the akonadi database, but as the payload (the
> content) is not yet available (it is still downloading), the payload is not
> transfered. Might explain mail loss on slow connections and using filters as
> well.
> 
> This needs some serious testing and if this is what happens, I'd consider a
> major bug.

It's the same scenario we saw some time ago already, with more obvious 
move/copy operations. The reason was a combination of nested transactions and 
the wrong transaction isolation levels. The attached patch against Akonadi 
master addresses this more generally than our fixes/workarounds from back 
then.

I'd appreciate some testing by someone who is able to reliably reproduce this 
problem (I never was, making it very hard to debug this).

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: akonadi-transaction-isolation.diff
Type: text/x-patch
Size: 2571 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120211/a4c07e80/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120211/a4c07e80/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list