Version: (using KDE 4.4.3) OS: Linux Installed from: Ubuntu Packages First, I want to add my voice to the chorus of complaints for releasing KAB in such an unfinished and unreliable version. Now for the bug: 1. I had my personal contacts in a simple std.vcf file. When the new KAB came I have imported them in the Personal Contacts folder resulting in a new folder located in .local/contacts filled with several .vcf files 2. I have 2 kubuntu partitions and both point to the same contact directory (on a third partition reserved for documents and files). In other words both versions of Kontact are accessing the same /contacts directory 3. If boot in partition-1 and I open a contact and add a home phone, for example, upon closing, the phone is saved in the specific .vcf file. 4. If I reboot in partition-2 and open the same contact, the phone is not there (although it is present in the .vcf file if I open it with kate). 5. Moreover, if I now add a work number to the same contact the .vcf file gets overwritten with a file containing the new work number and no home number. 6. Rebooting in partition-1 the same contact displays the home number (although it does not exist anymore in the .vcf file...where is it?) but no work number. 7. If Konact crashes for the many reasons described on this bug-reporting site and you loose the "Personal Contacts" address book, you have to go through the process of adding a new address book which re-reads the .local/contacts directory and you get whatever .vcf file is there which means that the home number entered at step 1 is completely lost. I have spent more than a week pulling my hairs and trying to figure-out why I was loosing data. I too protest against releasing a sw to a "stable" KDE-SC in the assumption that we are all programmer gurus and know how to find our way through the maze of bugs in akonadi/kontact. I have read many other bug reports and understand that there is only one programmer for kab. I respect his workload and personal priorities but I hereby ask him to respect my time and priorities as well. My contact data was in good condition and highly manageable before he started fixing an app that was not broken.
Hej Adrijan, your use case is quite a kind of a cornercase... The problem you are facing is, that Akonadi uses a cache to provide fast access to all data from the resources it is aware of. If you initially start KAddressBook on partition 1, Akonadi from partition 1 parses all contacts from $HOME/.local/share/contacts and stores them in the cache. Changes in KAddressBook are written back to the cache and the file system. Now if you start KAddressBook initially in partition 2, Akonadi from partition 2 also loads the contacts from file system and stores them in its cache (note that this is a different cache then the one on partition 1!). Changes to KAddressBook are again written back to the cache and the file system. Now if you start KAddressBook on partition 1 again, the vCards from the contact/ directory are not read in again, because they are already cached - under the assumption that nobody changed the files while Akonadi has not been running (which is a wrong assumption in your special case), so Akonadi doesn't know about changes you did from KAddressBook on partition 2. Changing data in KAddressBook will overwrite the data on the file system now. So one solution would be to always reload the cache when starting Akonadi, however that could be a serious performance problem... For this reason I'm not sure how to solve this problem... I'll talk with the other developers Ciao, Tobias
Thanks for the prompt response. First, my special case may be particular but it reveals one issue which is a problem of sharing a resource in KAB/akonadi. What if I decide to share the resource on the LAN or even with a smartphone. In the past I did have my contacts shared on lan and had no problem because there was a "save" button on KAB and also when opened it was reading the actual std.vcf file. Now if we also add cached contacts (which the user has no control upon) into the equation obviously the matter gets complicated. I am no database expert but I imagine that some other brilliant minds have found solutions for such issues on bigger databases. IMHO the problem starts when KAB overwrites the vcf file without notifying you that the file was changed (by another app or KAB instance) since last time you viewed it. I think this action in itself goes against any logical database management principles. Lastly, I have to ask you this question: If you say that my case is so singular how is one supposed to share resources in the new Kontact? Am I using it the wrong way? Or will I encounter the same problem if I decided to share a contact database,for example, on an LDAP server? I am asking this because I was really in the process of looking for a sharing solution as we may be moving to smartphones and I would logically like to have access to the same contacts database from home, work, and on the road.
Hej, well, you can't really compare our setup with a plain database setup. With a plain database setup, all data are stored in the db repository on the file system, so when you shut down one RDBM instance and start another instance on the same db repository, it will have all data available. In our case, the data is located in two places, on the file system and inside the cache, and you 'switch' only half of the data by using a shared file system but different caches... Actually we introduced Akonadi to avoid exactly this problem... the Akonadi server (and its cache) shall be the single instance where all accesses to the data go through. The network based resource has code to reload the contacts on every startup, so it always gets the most current version, just the 'Personal Contacts' resource has not. But as I told you, I'll talk with the other developers about this issue... Ciao, Tobias
SVN commit 1127307 by tokoe: Always synchronize the cache with the filesystem on startup to not miss any changes to the filesystem that has been done while Akonadi is not running BUG: 237127 M +4 -0 contactsresource.cpp M +3 -0 contactsresource.kcfg WebSVN link: http://websvn.kde.org/?view=rev&revision=1127307
I think this solves only part of the problem. What if I access the filesystem simultaneously with 2 apps. Or if the directory is shared and my wife accesses it with her laptop. I would suggest looking into: 1. Manual button in GUI to synchronise with filesystem. 2. If the user opens a contact for editing it should be loaded from the filesystem (synchronised). This should be done only for that specific contact to reduce traffic. This would ensure that one user is not editing what another user already did. 3. Currently, if the user edits a contact and closes the window the vcf file gets overwritten regardless if it matched or not what was in Akonadi's cache. Akonadi should notify the user if the vcf file it overwrites is not the same as was in the cache. (just like Kate does when you open a system file and the system modifies it after you opened it). Just an observation: It appears to me that the "personal contacts" type of resource was only intended to be used in a unique instance of Akonadi. See the warning file in the ./local/contacts folder. If it is indeed intended for a single user single instance then this bug should be addressed in a different manner. Akonadi should place some sort of lock on the directory, so that no other Akonadi instance or another app can use it. IDK if this is possible. But I know that you can't just rely on a text file in a folder to tell users not to use that kind of resource in a multi-user/instance environment. If this can't be done then I would just treat all resources the same way whether they are shared (on the network) or not. This will also eliminate the current confusion when adding address-books.