Bug 304732

Summary: Calendar Dir Resource does not check files on startup
Product: [Frameworks and Libraries] Akonadi Reporter: Stefan Kebekus <stefan.kebekus>
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: critical    
Priority: NOR    
Version: 4.9   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:

Description Stefan Kebekus 2012-08-07 15:23:46 UTC
I use a calendar dir resource (in German "KDE Kalender (herkömmlich)") to store tasks in a directory. I use the "unison" file synchronizer to sync the directories on my laptop computer and the desktop in my office.

When I sync the files while akonadi is running, the changes are reflected immediately, as expected. When I sync the files when akonadi is not running, akonadi does not seems to realize on startup that the files have changed, and shows the old tasks list. This leads to dis-synchronization, and eventually to data loss.

One possible remedy would be that akonadi (or the resource) updates its data every time akonadi is started, or perhaps at regular (rather short) intervals. Another possible solution would be that akonadi (or the ressource) stores file time stamps, and check timestamps on startup to ensure that data is up-to-date. Another possible solution (perhaps the cleanest solution of all) would be that akonadi always uses the data stored in files, and does not duplicate the data.

Reproducible: Always

Steps to Reproduce:
1. make sure akonadi is not running
2. modify files, e.g., by synchronizing with another computer
3. start akonadi
Actual Results:  
kontact shows tasks lists that reflects the state of files BEFORE the sync

Expected Results:  
kontact/akonadi should update tasks lists
Comment 1 Denis Kurz 2016-09-24 20:41:15 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 2 Denis Kurz 2017-01-07 22:45:20 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.