Version: (using KDE 4.4.1) Installed from: Fedora RPMs For the purpose of easy synchronisation with my phone and other places, I need to keep my contacts in .vcf file. This has worked for years, and now it is broken. KDE4 simply sucks. (Yes, I know it is bad to say such things in a bugreport, but being nice does not help. Hope you finally realise how bad the situation is when you force users to do things they know to be bad. I refer also to bug #233078) I've removed all the automagically created addressbooks and started from scratch. I've added only one addressbook resource which refers to the old std.vcf file. In the addressbook properties, Read only is NOT checked, the format is vCard and the location is ~/.kde/share/apps/kabc/std.vcf The contacts are displayed okay. However, when I add a contact, it does not get added to the file, even if it shows within the list! When I log out, the modification time of the std.vcf file gets updated, but the contents of the file is left untouched. But after running kaddressbook again, the newly added contact is there - WHERE THE HECK DOES IT COME FROM??? AND WHY THE HECK THE MTIME GETS UPDATED WHEN NOTHING IS CHANGED???
(In reply to comment #0) > KDE4 simply sucks. (Yes, I know it is bad to say such things in a > bugreport, So why do you do it then anyway? > but being nice does not help. Hmm? Doesn't have your mommy told you that being nice is a basic part of social communication? > I've removed all the automagically created addressbooks and started from > scratch. I've added only one addressbook resource which refers to the old > std.vcf file. Which kind of resource? 'Traditional Addressbook' or 'vCard file' resource? The former shouldn't be used anymore. > However, when I add a contact, it does not get added to the file, even if it > shows within the list! Can't reproduce this here with vanilla KDE SVN trunk, both resources work fine. > But after running kaddressbook again, > the newly added contact is there - WHERE THE HECK DOES IT COME FROM??? No reason to cry, Akonadi contains a cache, so you see the cached data.
(In reply to comment #1) > (In reply to comment #0) > > KDE4 simply sucks. (Yes, I know it is bad to say such things in a > > bugreport, > So why do you do it then anyway? I've explained that too sad you fail to listen > > but being nice does not help. > Hmm? Doesn't have your mommy told you that being nice is a basic part of social > communication? yes, she told me unfortunately, I'm too old by now and I have found out already that life is not a fairytale sometimes, people just need kicking in the ass ... and sometimes even that does not help, like we can see here (but at least it got attention, which is more than we can say about some other bugs rotting here for ages ...) > > I've removed all the automagically created addressbooks and started from > > scratch. I've added only one addressbook resource which refers to the old > > std.vcf file. > Which kind of resource? 'Traditional Addressbook' or 'vCard file' resource? I don't remember ... the one that allowed me to use single .vcf > The former shouldn't be used anymore. why is it present then? > > However, when I add a contact, it does not get added to the file, even if it > > shows within the list! > Can't reproduce this here with vanilla KDE SVN trunk, both resources work fine. sticking your head in the sand and saying "if a bug does not show on my system it does not exist" does not help the case svn says there hasn't been any possibly relevant commit to kaddressbook in the last FOUR months while 4.4.1 is out for one and a half month => reopening ... you say it's not directly in kaddressbook? - feel free to reassign > > But after running kaddressbook again, > > the newly added contact is there - WHERE THE HECK DOES IT COME FROM??? > No reason to cry, Akonadi contains a cache, so you see the cached data. no, I just see shit! the purpose of cache is to speed up access, not to keep completely different set of data and this doesn't explain the other question ...
(In reply to comment #2) > > > KDE4 simply sucks. (Yes, I know it is bad to say such things in a > > > bugreport, > > So why do you do it then anyway? > > I've explained that There is nothing to explain, this is a bug tracker not a user forum! > sometimes, people just need kicking in the ass ... Well, then you are at the wrong place, we like neither ass kicking nor impolite people... Do not expect any help in this case > > Which kind of resource? 'Traditional Addressbook' or 'vCard file' resource? > > I don't remember ... the one that allowed me to use single .vcf Then you should maybe remove the resource you've added and add a 'vCard file' resource... from you previous description it sounds like you've added the former which is known to be buggy. > > The former shouldn't be used anymore. > > why is it present then? For most users/distribution/kde version combination this resource works without problems. > > Can't reproduce this here with vanilla KDE SVN trunk, both resources work fine. > > sticking your head in the sand and saying "if a bug does not show on my system > it does not exist" does not help the case Well, if I (the developer) can't reproduce it, I have no way to fix it... > svn says there hasn't been any possibly relevant commit to kaddressbook in the > last FOUR months while 4.4.1 is out for one and a half month => reopening Commits to KAddressBook are irrelevant here, the behavior is caused by the resource, which is a completely different code base. > > No reason to cry, Akonadi contains a cache, so you see the cached data. > > no, I just see shit! So it is brown and smells bad? > the purpose of cache is to speed up access, not to keep completely different > set of data It doesn't keep completely different set of data, the data of the cache just have not be written back to the original source (aka vCard file).
(In reply to comment #3) > There is nothing to explain, this is a bug tracker not a user forum! then why do you keep prolonging the offtopic discussion? > > sometimes, people just need kicking in the ass ... > Well, then you are at the wrong place, we like neither ass kicking nor impolite > people... > Do not expect any help in this case now, that is funny :-) you (the KDE developer community as a whole) started to misbehave, treat users bad, causing harm to millions of people(*), acting like gods, laughing into users faces, accusing the distributors and hardware/drivers vendors of your own faults etc. now when an user strikes back (not much to do, I can't break your machine just like you've broken mine, so just verbally), you play the most aggrieved person in the world that's what I call hypocrisy :-) (*) for example I've just read recently that Fedora is estimated to 24M installations, and KDE is not just 1% minority ... > > > Which kind of resource? 'Traditional Addressbook' or 'vCard file' resource? > > > > I don't remember ... the one that allowed me to use single .vcf > Then you should maybe remove the resource you've added and add a 'vCard file' > resource... from you previous description it sounds like you've added the > former which is known to be buggy. ok, I've tried so, adding a vCard file resource seems to work => keeping the bug closed if this is the only supported way to use .vcf ... but creating bug #234259 to get rid of the unsupported way > > > The former shouldn't be used anymore. > > > > why is it present then? > For most users/distribution/kde version combination this resource works without > problems. this sounds like "when there is full moon and the night is not cloudy and you stand on your left leg ..." note that I've tried bug #234259 on Fedora 13 with KDE 4.4.2 ... > Well, if I (the developer) can't reproduce it, I have no way to fix it... simply not true ... > Commits to KAddressBook are irrelevant here, the behavior is caused by the > resource, which is a completely different code base. if that was clear then the bug should have been reassigned in the first place; users are not expected to understand code hierarchy ... > > > No reason to cry, Akonadi contains a cache, so you see the cached data. > > > > no, I just see shit! > So it is brown and smells bad? well, I know that KDE developers expect everyone to have the latest&greatest hardware, but I still don't own a scent delivery system, so I can't tell, sorry > > the purpose of cache is to speed up access, not to keep completely different > > set of data > It doesn't keep completely different set of data, the data of the cache just > have not be written back to the original source (aka vCard file). ... which in other words means that the original source has completely different set of data; wasn't that an oxymoron? anyways, thankyou for leading me to a workaround for this bug I won't reopen it again, as stated above, I won't force fixing a bug in a component which is no longer supported - even if proper action would be to reopen and then let the owner to close this as WONTFIX (you choose wrong resolution intentionally to have nicer statistics? - seems like a trend these days, nobody dares to use WONTFIX, I'm getting INVALID/NOTABUG on obvious problems a lot recently ...)
(In reply to comment #4) > (In reply to comment #3) > > Well, if I (the developer) can't reproduce it, I have no way to fix it... > > simply not true Unfortunately it is. With no way of reproducing a problem there is no way of checking whether a change fixes the problem or even improves the situation. Under some circumstances it might be possible to guess what the problem could be, create a patch for that, have the user build the software with the patch applied and check whether it works and repeat whether it doesn't. It is therefore usually more viable to determine whether there is a different solution to the actual goal, in this case using the specialized VCard resource.
I am having problems with remote VCF files simply disappearing from the addressbook. The folders are still there, but there are no contacts in them. The addressbook and Akonadi still seem to be alpha quality. As such, we really need a way to operate our productivity tools without using them.
Following up from bug #259067: I experienced the same error as the original poster, with the new vCard file resource (local std.vcf file not being updated, while addressbook keeps being updated in the Akonadi cache only). Deleting the addressbook (in kaddressbook, not the file itself) and re-creating it with the same type from the same file seems to have solved the problem. I suspect a real bug exists, though I don't know how to help reproduce it (I tried to repeat the actions that led to this state, that is, copy some other file over std.vcf when Akonadi is down, and it did not reproduce).