[kdepim-users] Frequent coruptions of data base. Any remedies?

[Kishore Jonnalagadda]

I just read your blog and it explains this well. Could you slightly expand
on the format used for imap cache? Folder hierarchy and how we can maybe
read and understand the database files?

Here is the reason I ask for the above info. I use disconnected imap with
gmail and if you use gmail/imap you would know that it has a pseudo
"[Gmail]" folder under which it has its "sent", "thrash" etc. This [Gmail]
folder itself can contain no mail but for some reason, akonadi thinks it
has 14 mail and tries to retrieve them when I clickmon the folder and
starts endlessly spinning. I noticed the 14 number in the folder properties
dialog. Now I want to tell akonadi to dump that's folder and rebuild its
index for it. I don't want to do that for the full account as that process
took almost 48hrs the last time.

For some info on the way I use my system, I rarely restart but
suspend/resume several times a day and my home dir is on a local hdd. By
the way, akonadi seems to be very poor at recognizing internet connection
loss. I often have to restart akonadi but sometimes toggling kmail
online/offline helps.

--
Cheers!
Kishore
On Nov 13, 2011 1:34 PM, "Andras Mantia" <amantia at kde.org> wrote:

> Stephan Diestelhorst wrote:
>
> > Is there a reason why they are not default? If my email were POP, I
> > would have lost considerable amounts of mail by this.
>
> This is common misconception: losing the akonadi database will NOT lose
> your
> mails. The database stores two things:
> - it acts as a cache
> - it stores metadata information (tags, extra flags)
>
> For POP3, what you'd lose it tags. For POP3 the mail body is cached only
> temporary, it is deleted after a time anyway. Flags are stored encoded in
> the filename (well, if you have KDE 4.7.2+).
>
> For disconnected IMAP the database stores the whole mail, but of course
> there is no data loss, as the mails are also stored on the server.
>
> Neverthless having a corrupted database is bad, and this being a mysql bug
> puts us in a bad situation, as MySql is the most tested backend and the
> current default (sqlite is unreliable, postgres might work, although it is
> not that well tested), as makes the applications unusable and takes up
> considerable amount of time (user's time).
>
> > The MySQL folks suggest to dump the database and manually feeding the
> > data back in there, maybe AKonadi could do that?
>
> Question is, how often? When? And that would double the amount of space you
> need in the $HOME.
>
> BTW, is you $HOME on an NFS share? AFAIK that has problems with mysql
> databases especially on suspend/resume.
>
> Andras
> _______________________________________________
> KDE PIM users mailing list
> Subscription management:
> https://mail.kde.org/mailman/listinfo/kdepim-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20111113/797eb7fe/attachment.html>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users