I've just had a somewhat catastrophic "upgrade" to Fedora 16, basically a re-install due to the upgrade process failing, perhaps linked to the subsequent hard disk failure

Anyhow, it means I've been moved up to KDE 4.7.4 (?). I've managed to get my diary, KJots, and KOrganizer data back, but I can't find my address book anywhere. Can someone tell me where I can find the data on my old disk and how I can get it into my new setup?

Many thanks
Mark

Kontact is not part of KOffice, Perhaps one of the moderators will move your post to the correct forum.

Moved to Office & Productivity.

Try looking in ~/.kde4/share/apps/kabc/std.vcf

Sorry to have originally posted in the wrong place.

I've not got a ~/.kde4, just ~/.kde, don't know if that's an important difference.

Going to my copy of the duff disk, in kabc, I've got std.vcf, and std.vcf_1 to std_vcf_7, but they're all empty. I wonder if they're casualties of a duff disk? I'll see if I can revive the disk itself enough to have a more thorough look there.

Many thanks.
Mark

For a time, some distros offered both KDE 3 and KDE 4, differentiating them with ~/.kde and~/.kde4. If you have only ~/.kde that's almost certainly the place to look, so no worries

If std.vcf and all its backups are empty, either you have been backing up an empty addressbook for some time, or you have lost them through corruption. If you have made any backups anywhere with old copies in, you would at least regain a good proportion of your contacts. Simply copy the backed up std.vcf over the empty one.

Good luck!

I'm afraid I've not been making any backups at all.
I know, but it's Linux, it never goes wrong... Alright, more to the point, I'm new(ish) on Linux and KDE apps.

So what I'm actually looking for is where's the data, not where's the backups.

If it's possible to do, I (probably) know enough to be led by the hand through a process to recover the data.

So, where's the data?

If they are truly empty, and you have no backups, it's gone, and can't be recovered. What happens if you open konsole and type

ls -al .kde/share/apps/kabc/std.vcf*
?

Code: Select all

drwxrwxr-x.  2 Mark Mark 4096 Dec 31 16:04 lock
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_1
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_2
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_3
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_4
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_5
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_6
-rwxrwxrwx.  1 Mark Mark    0 Dec  7 08:41 std.vcf_7

Note -: This is not my current home directory. It is in the home directory on my old, now-unbootable, disk. Whilst that disk won't boot, I can get a lot of data off it. So, although I don't have backups, I do have most of the disk available. That's why I'm still (ever) hopeful that if I can find where the data is stored I can reclaim it.

Do you mean that the data is stored in vcf files for normal use?

It seems to me that now the data is stored, via Akonadi, in MySql. I don't know if that what the case in the version I had in Fedora 15.

Thanks for sticking with me on this
Mark

Much depends on which versions you've used before. The old addressbook stored files as std.vcf (and my personal preference is to use that file as a fall-back, while akonadi is stabilising). If you have only used a KDE addressbook within the last year or so, you probably have only used the akonadi version, so you should look (on the old disk) at ~/.local/share/contacts. If you see lots of smallish files with strange names, they are your contacts and can be copied into the same place on the new disk. Hopefully the database will pick them up and index them from there (but personally, I'd copy the lot into std.vcf, in case it doesn't). I don't know the inner workings of akonadi, so I'm not promising the re-indexing

The std.vcf file you list are indeed all empty, not just lost to visibility, so there's no point in going any further down that particular path. The akonadi storage path is your next port of call. If you find contact records there, you then need to ensure you have an akonadi resource pointing to your newly copied records.

Yes, it's relatively recently, or perhaps more pertinently, I keep up-to-date by accepting updates.

I've not got a "contacts" folder under there. I do have an akonadi folder, is has MySQL data in it. I was hoping that that wasn't my only option, since I've had a brief play with it and it's only ended in tears.

Akonadi runs it's own instance of MySQL, so I have to try to get those old-system live files into my new system...

Any tips or hints gratefully received

That's definitely too technical for me, sorry If you can find the Akonadi directory under ~/.local on the old disk, it may be enough to just copy the contents across?

A general tip next time you're not sure where things are: update your system's database using "updatedb" as root.

Then, as normal user, do a "locate _file_name_", in other words "locate std.vcf".

Hi Both,

Thanks for your help.

What's "update_db" doing? Copying data from the MySQl tables to vcf file/s?
Might that rescue my data from the old MySQL setup?

M

No, it has nothing to do with mysql.

From man updatedb:

updatedb(8) updatedb(8)

NAME
updatedb - update a database for mlocate

SYNOPSIS
updatedb [OPTION]...

DESCRIPTION
updatedb creates or updates a database used by locate(1). If the database already exists, its data is reused to avoid rereading directories that have
not changed.

updatedb is usually run daily by cron(8) to update the default database.

It basically helps you find files in your system. updatedb updates the internal database which you call on when using the locate command.

I use calendar, address book, TODO lists, Akregator, not to mention KMail (imap).

The problem is always with a backup. All those apps data are stored in different places. There should definitely be ONE magic button to make a backup!

Now I have to look up where my data is kept. It’s stupid. And I’m not the only one with this problem.

What’s more. The wiki on techbase is misleading and it’s not up-to-date. For example it doesn't tell about KJots data.

Sorry, but is should have been implemented a long time ago!