opensuse 13.1 x86_64 , kde 4.14.3 1. one week ago there was an update of kde pim thus akonadi. since i get a problem . for one message i move it to the dustbin then it disappears from the inbox and it is well copied in the dustbin then i go to another folder then i go back to the inbox then the message is here again ! i can move it to another folder without any pb . when i use akonadiconsole : - i can see a bubble saying there is 1 message in the folder - when i click on the folder the displayed contents (with model "mail") is empty 2. yesterday there was another update of kde pim since i get another pb with one message i move it to another folder then it disappears from the inbox and is well copied to the other folder . then i go back to the inbox then the message is still here ! then i delete it and it is well deleted but today i see the message in the destination folder of the move is no more here ! it is well in the dustbin then i move it again with success from dustbin to the destination folder Reproducible: Always
I'm a google code-in student who is doing a bug triaging task. Can you provide which version of kmail are you using?
kmail 4.14.3
Hi, I confirm the same behaviour with a fresh install of Kubuntu 15.04/KDE 4.14.6/KMail 4.14.6/Akonadi amd64/vivid 1.13.0-2ubuntu4. After move, the message is not shown in the origin folder at first, is shown in the target folder as it should, but then is also shown in the origin folder after navigating back to it. The end result is a copied message instead of a moved message (with tray notification too!). This behaviour is extremely annoying. Moving messages is a very basic function.
A few questions to see if this problem (if still persisting) is related to bug #357179: - Are we talking about local folders here? - Can you check if the target exists on the file system as a folder (vs. being just cached inside the Akonadi database)? Typically the local folders are at a location like ~/.local/share/local-mail, make sure to also check for hidden files there. Subfolders are names ".SUBFOLDER.directory". I have the suspicion that moving/deleting fails if the source directory exists on the file system, but the target directory does not.
>> Are we talking about local folders here? yes >> Can you check if the target exists on the file system as a folder i does not exist as a folder in the file system in ~/.local/local-mail htere are only cur new tmp
no more problem