workaround for getting DAV groupware resource out of broken state

[Erik Quaeghebeur]

Dear List,


I had the issue that a DAV groupware resource would get one or more dirty 
entries (dirty=1 for its row in akonadi PimItemTable) for some unknown 
reason. Afterwards, even after removing those entries from akonadi (using 
akonadiconsole's Browser), the resource would be in a broken state. It gave 
an unhelpful message and would not restart. I was forced to remove and 
readd the resource.

Encountering the issue again today, I looked at all akonadi-related 
locations in my home directory for things outside of the database 
proper—which I was quite sure I had cleaned up—could have an influence. In 
~/.config/akonadi I encountered files with names of the type 
"agent_config_akonadi_davgroupware_resource_23_changes.dat". These are 
binary files, but strings were visible inside. In my case they contained 
versions of the entry that was dirty.

I decided to try out the following:

1. remove the dirty entry from the database
2. stop akonadi
3. delete the …_changes.dat file in question
4. restart akonadi

After that, the DAV groupware resource came to life again!

Even if still inconvenient, it is a far better workaround than nuking the 
resource.

Some questions and feedback for any developers reading this:

* I think it would be better to place these *_changes.dat files in a 
different location, such as next to the database in ~/local/share/akonadi 
or perhaps in ~/.cache/akonadi. 

* Is it safe to delete the …_changes.dat file with akonadi running?

* Would it be possible to make the error message more informative, e.g., by 
mentioning an inconsistency between the database and the …_changes.dat 
file?


Best,

Erik