https://bugs.kde.org/show_bug.cgi?id=364114
--- Comment #4 from Martin Steigerwald <mar...@lichtvoll.de> --- I see how it is challenging to solve this within current Akonadi design. If using a folder ID that is just stored within the database, it won´t detect manual moves. But well, it could write a .folderinfo file into each folder containing a unique hash of the folder. It would then store in database folder xyz has this internal Akonadi ID and this hash and is currently located at this path. I wonder whether this changes the consequence of a database loss, but I don´t think so, I think it can even provide a path to make filter handling much more robust. If the filter rules stores the hash of the folder, akonadi mailfilter agent can ask Akonadi about the internal database ID for the folder and thus as long as the user does not remove the .folderinfo or whatever it is called file from the folder, the filter rules would still work after a complete database loss. (Of course that doesn´t solve this issue for IMAP accounts, but it would be a start.) For the individual mail items in the database Akonadi can still use an internal ID, cause on database loss, this information is lost as well, so it will have to reindex all the folders anyway. -- You are receiving this mail because: You are watching all bug changes.