Hi,

for reasons explained in the thread "akonadi confusion" I need to recreate my local mail folders from the akonadi data base and the cache stored in ~/.local/share/akonadi/file_db_data. My current version of the repair script (in perl) can recreate the local mail directories (i.e. all .blabla.directory and blabla/cur, blable/new and blabla/tmp) from the information in akonadi, table collectiontable.

Now I need to fix the akonadi database itself. The collection table has columns
id, remoteID, remoteRevision, name, parentID, resourceID, ...
For all those directories recreated by my script, the values for remoteID, remoteRevision are void. I guess this is a broken state. I also guess that this is the explanation for bug
https://bugs.kde.org/show_bug.cgi?id=290589. But what should go in there ?
My guess is that remoteID should be the basename of the directory (which is the same as "name") if parentID is non-void. It seems to be the full path if the parentID is void. Is this correct ?
What shout go into remoteRevision ? It looks like a time stamp. Or can I safely leave it empty ?

Christoph Pospiech

Hi,

same kind of question for the mails I need to recreate. The akonadi table pimitemtable has columns
id, rev, remoteID, remoteRevision, collectionID, ... , dirty.
For all those mails I need to recreate, remoteID and remoteRevision are void and dirty = 1.
The remoteID should be the file name (mail dir format), correct ? What should go into rev and remoteRevision ? What does dirty=1 precisely mean ? Do I need to set it to 0 when the mail has been recreated ? Or - even better - can I convince akonadi somehow to write the "dirty=1" cache contents into the directory specified by collectionID - which just have been resurrected by my script ?

Christoph Pospiech

Hi,

I guess I found everything I need. Most of the above guesses appear to be true.

Christoph Pospiech