Version: 1.99.0 OS: Linux I was moving about 1gb of e-mails from local folders to imap account. In the process system become unresponsive and had to be rebooted. After restart all the mails that were supposed to be moved are lost. The local folder is empty, on the imap account there's only several hundreds empty mails. Reproducible: Didn't try Steps to Reproduce: As in summary Expected Results: Not deleting my e-mails, even when the process fails or is interrupted. OS: Linux (i686) release 3.0.0-13-generic Compiler: gcc
The imap account in kmail shows all the e-mails, but when you try to display any of them you get "Remote id is empty or invalid" error.
Do you see the mails with another client? Were they really lost or it is KMail that is not showing them?
(In reply to comment #2) > Do you see the mails with another client? Were they really lost or it is KMail > that is not showing them? They are realy lost. I verified with webmail client.
Hi. I've this problem when I move mails (e. g. from my local sent folder) to an online IMAP account. First the mail appears for some time and then disappears. I get the error message: Store failed, server replied: A013183 BAD Command Argument Error. 11 I'm using 4.11 RC2 and the IMAP account is on an Exchange server. Cheers, André
I forgot to mention when I copy a mail I also get the error message but the mail is copied successfully.
On Thursday 08 August 2013 17:18:52 Andre Woebbeking wrote: > https://bugs.kde.org/show_bug.cgi?id=287356 > > --- Comment #5 from Andre Woebbeking <woebbeking@kde.org> --- > I forgot to mention when I copy a mail I also get the error message but the > mail is copied successfully. Oops, that is wrong. When I use another mail client on that IMAP account the copied mails are not shown. Does Akonadi add them in the online IMAP resource "virtually"?
Moving items between two resources has a major weakness: it is split into two separated operations - in the resource that we are moving the item from the operation is translated into "remove", in the destination resource it is translated into "insert". The problem is that when "insert" fails, we have no way of reverting the "remove", because it has happened in a different process and so data are lost. Good news: this will be solved with server-side change recording, once I implement it :) Bad news: I don't think it can be easily worked around in the meanwhile.
Couldn't the "remove" only be done if the "insert" was successful?
Unfortunately not, because Akonadi server sends notification "Move item 1 from resource A collection 3 to resource B collection 10" to both resources at once and the translation happens in the resources. Resource A will interpret the notification as "remove" and resource B as "insert". Even worse, the translation happens in resource's Monitor and the ResourceBase will only get the "Remove" or "Insert" notification, without actually being able to map it back to the "Move" notification. I'll still try to think of some solution if I have some time. I think the primary focus in this case now should be on fixing your IMAP resource to make moving work :)
Git commit c561149538336804f212f5a12ea6cf3d1a3a19f5 by Andre Woebbeking. Committed on 27/09/2013 at 20:19. Pushed by woebbe into branch 'KDE/4.11'. Don't bother IMAP servers with not supported flags Created a new method ResourceTask::fromAkonadiToSupportedImapFlags() to convert Akonadi to IMAP flags supported by the server and use it everywhere instead of fromAkonadiFlags(). fromAkonadiFlags() was made private to make it impossible to call it by accident. Related: bug 278082 FIXED-IN: 4.11.3 REVIEW:112724 This also reduces the risk to trigger 287356 as the insert on the IMAP server doesn't fail due to unsupported IMAP flags. M +1 -1 resources/imap/additemtask.cpp M +2 -2 resources/imap/changeitemsflagstask.cpp M +2 -15 resources/imap/changeitemtask.cpp M +21 -0 resources/imap/resourcetask.cpp M +5 -0 resources/imap/resourcetask.h http://commits.kde.org/kdepim-runtime/c561149538336804f212f5a12ea6cf3d1a3a19f5