I have renamed an IMAP folder in KMail. The folder was named svn and the new name is code. The folder is renamed correctly on the server side, and also the client shows the new name. However, new mails are not received for this folder. Updating the folder gives the following error message in akonadi console: AgentBase(akonadi_imap_resource_2): Auswählen fehlgeschlagen, die Serverantwort lautet: A058401 NO Invalid identifier In English it is something like: […]: Selection failed, the server response is: […] it seems like akonadi still uses svn as remoteid: 203871 UID MODIFY 502 PARENT 490 NAME "code" REMOTEID ".svn" REMOTEREVISION "" uidnext "1370" collectionquota "0 0" collectionflags "\\Answered \\Flagged \\Draft \\Deleted \\Seen NonJunk $REPLIED $FORWARDED \\*" imapacl "username lrswipcda %% " timestamp "1436883498" uidvalidity "1374755801" collectionannotations "/shared % /shared/check % /shared/checkperiod % /shared/comment % /shared/sort % /shared/specialuse % /shared/thread % /shared/vendor/cmu/cyrus-imapd/duplicatedeliver false % /shared/vendor/cmu/cyrus-imapd/expire % /shared/vendor/cmu/cyrus-imapd/lastpop % /shared/vendor/cmu/cyrus-imapd/news2mail % /shared/vendor/cmu/cyrus-imapd/partition default % /shared/vendor/cmu/cyrus-imapd/pop3newuidl true % /shared/vendor/cmu/cyrus-imapd/pop3showafter % /shared/vendor/cmu/cyrus-imapd/sharedseen false % /shared/vendor/cmu/cyrus-imapd/sieve % /shared/vendor/cmu/cyrus-imapd/size 5188345 % /shared/vendor/cmu/cyrus-imapd/squat % /shared/vendor/cmu/cyrus-imapd/uniqueid 4ba423ed51f11bd9" imapquota " %%%% STORAGE % 0 %%%% STORAGE % 0" highestmodseq "2641" Reproducible: Always
deleting the code folder on the client did not delete the code folder on the server side. afterwards the code folder from the server is fetched. Therefore deleting the buggy folder is a workaround, but the original issue "remote id not updated in local folder" is still valid.
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.