<p>On Nov 14, 2011 12:22 AM, "Andras Mantia" <<a href="mailto:amantia@kde.org">amantia@kde.org</a>> wrote:<br>
><br>
> Kishore Jonnalagadda wrote:<br>
><br>
> > I just read your blog and it explains this well. Could you slightly expand<br>
> > on the format used for imap cache? Folder hierarchy and how we can maybe<br>
> > read and understand the database files?<br>
><br>
> The answer unfortunately is not that easy, it'd be along the side of<br>
> explaining the database layout. You can run the akonadiconsole tool and try<br>
> to explore the database. In short - in case of mails: collections are<br>
> folders, pimitems are mail, parts are parts of mails (envelope, header,<br>
> body), payload is the actual content of a part. remoteId is also important,<br>
> it identifies where the cached item points to (e.g your IMAP folder for a<br>
> collection).<br>
>  As explained in the blog, sometimes the payload data is stored in an<br>
> external file. It will still have an entry to it in the database though.</p>
<p>Ill try if I can lookup the database for the above info but I doubt ill succeed! :)</p>
<p>> > Here is the reason I ask for the above info. I use disconnected imap with<br>
> > gmail and if you use gmail/imap you would know that it has a pseudo<br>
> > "[Gmail]" folder under which it has its "sent", "thrash" etc. This [Gmail]<br>
> > folder itself can contain no mail but for some reason, akonadi thinks it<br>
> > has 14 mail and tries to retrieve them when I clickmon the folder and<br>
> > starts endlessly spinning. I noticed the 14 number in the folder<br>
> > properties dialog.<br>
><br>
> This looks like either a bug in the IMAP agent or in GMail's imap<br>
> implementation. Have you reported this bug on <a href="http://bugs.kde.org">bugs.kde.org</a>? I don't use<br>
> gmail, so can't comment on it, but other devels I know were looking at gmail<br>
> compatibility and already fixed some issues.</p>
<p>Done now. <a href="https://bugs.kde.org/show_bug.cgi?id=286556">https://bugs.kde.org/show_bug.cgi?id=286556</a></p>
<p>> > Now I want to tell akonadi to dump that's folder and<br>
> > rebuild its index for it. I don't want to do that for the full account as<br>
> > that process took almost 48hrs the last time.<br>
><br>
> Unfortunately there is no such thing as index rebuilding. The closes thing<br>
> is Update Folder from the context menu (or Update Folder and subfolders).<br>
> This is what synchronizes the cache with the real data.</p>
<p>I tried that several times but it did not help.</p>
<p>> > For some info on the way I use my system, I rarely restart but<br>
> > suspend/resume several times a day and my home dir is on a local hdd. By<br>
> > the way, akonadi seems to be very poor at recognizing internet connection<br>
> > loss. I often have to restart akonadi but sometimes toggling kmail<br>
> > online/offline helps.<br>
><br>
> This is a known bug inside the IMAP agent - I also suffer from it, the<br>
> developer who wrote the IMAP agent is aware of it and I hope he will fix it<br>
> short term.<br>
>  Switching the agent offline/online should help (you can do it from<br>
> akonadiconsole if turning KMail itself offline/online does not help).</p>
<p>I sure hope for that too. I was in a rather embarrassing situation a few days back... I took my laptop to a clients placed, resumed it and hooked it up to a projector and began my presentation. Then several minutes later the imap resources started bombarding notification back to back and I had a tough time getting rid of them as they just kept on popping up! :( For next time ill have to create a presentation activity with notifications disabled.<br>

--<br>
Cheers!<br>
Kishore<br>
</p>