Summary: | Already-existing MAILDIRs not getting indexed with KDE 4.11 | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | whatifgodwasoneofus |
Component: | Nepomuk Feeder Agents | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | major | CC: | cfeck, dvratil, joerg.schaible, kitts.mailinglists, koyukuk, luisfe, mail, me, vkrause, whatifgodwasoneofus |
Priority: | NOR | Keywords: | regression |
Version: | 4.11 | ||
Target Milestone: | --- | ||
Platform: | Chakra | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
whatifgodwasoneofus
2013-09-15 10:33:32 UTC
I have a similar problem but with a disconnected IMAP resource. Is there a workaround that i can use? Is my problem related to this bug? I can confirm this behavior for KMail 4.10.5 (see http://thread.gmane.org/gmane.comp.kde.users.pim/21868) I'm seeing the same issue here on KDE 4.11.3, Arch Linux x86_64. Same here on debian testing, KDE 4.11.3. When using nepomukpimindexerutility to index a mail I get the message: nepomukpimindexerutility(12977) FeederPluginloader::feederPluginsForMimeType: No feeder for type "inode/directory" found nepomukpimindexerutility(12977) ItemQueue::fetchJobResult: Not all items were fetched: 0 1 So maybe the pimindexer does not index Maildirs because it lacks a plugin and the fileindexer doesn't know it is mail and therefore can't tell akonadi/kmail? I think that the problem is not the akonadi_nepomuk_feeder but Akonadi::ItemFetchJob that does not fetch items. Say you have an akonadi item 123456 that want to be passed to Nepomuk, try qdbus org.freedesktop.Akonadi.Agent.akonadi_nepomuk_feeder / org.freedesktop.Akonadi.NepomukFeeder.forceReindexItem 123456 You will get something like akonadi_nepomuk_feeder(5709) ItemQueue::fetchJobResult: Not all items were fetched: 0 1 It happens with mails, contacts and everything. The Akonadi::ItemFetchJob invoked from ItemQueue in Nepomuk Feeder fetches only cached items - if there's an item that does not have the payload cached in Akonadi yet, it will be skipped. Please open Akonadi console and in "DB Console" tab, run following query: SELECT PartTable.*, PartTypeTable.* FROM PartTable LEFT JOIN PartTypeTable ON PartTable.partTypeId = PartTypeTable.id WHERE PartTable.PimItemId = 123456 Replacing 123456 with ID of an item you know does not work, post the output here (or screenshot, the table is hard to copy) Then, switch to Raw Socket tab and send following commands one by one 0 LOGIN test 1 CAPABILITY (NOPAYLOADPATH) 2 UID FETCH 123456 (CACHEONLY EXTERNALPAYLOAD PLD:ENVELOPE PLD:HEAD PLD:RFC822 ALLATTRIBUTES) And paste here the replies from the server. Remember to strip sensitive information. You can string content of the reply, just make sure you keep strings like PLD:HEAD[1] {123} (they can appear in the middle of the reply, too) OK, using akonadi master, for the DB query I get id pimItemId partTypeId data datasize version external id name ns 57869 28999 9 ("Thu, 29 Sep 2011 21:21:29 -0300" "Re: diciembre" … 362 1 0 9 ENVELOPE PLD 57869 28999 10 0 1 0 10 HEAD PLD 80978 28999 11 0 1 0 11 RFC822 PLD So headers and full mail is not in the database. Now, I query on the raw socket, got: * OK Akonadi Almost IMAP Server [PROTOCOL 35] 0 LOGIN test 0 OK User logged in 1 CAPABILITY (NOPAYLOADPATH) 1 OK CAPABILITY completed 2 UID FETCH 28999 (CACHEONLY EXTERNALPAYLOAD PLD:ENVELOPE PLD:HEAD PLD:RFC822 ALLATTRIBUTES) * 28999 FETCH (UID 28999 REV 4 MIMETYPE "message/rfc822" COLLECTIONID 86 PLD:ENVELOPE[1] {362} ...here appears the envelope as in the database... PLD:HEAD[1] {3579} ...Many headers of the message... PLD:RFC822[1] {5051} ...Full message here... 2 OK UID FETCH completed NOW, after performing the raw queries, the item is found by nepomuk, if I perform a new database query I get id pimItemId partTypeId data datasize version external id name ns 57869 28999 9 ("Thu, 29 Sep 2011 21:21:29 -0300" "Re: diciembre" … 362 1 0 9 ENVELOPE PLD 57869 28999 10 "headers here" 3579 1 0 10 HEAD PLD 80978 28999 11 80978_r0 5051 1 1 11 RFC822 PLD And 80978_r0 is a copy of the mail in akonadi/file_db_data cache folder. If I restart akonadi, the cached file disappears, the database query gives again the first answer. id pimItemId partTypeId data datasize version external id name ns 57869 28999 9 ("Thu, 29 Sep 2011 21:21:29 -0300" "Re: diciembre" … 362 1 0 9 ENVELOPE PLD 57869 28999 10 0 1 0 10 HEAD PLD 80978 28999 11 0 1 0 11 RFC822 PLD But now the difference is that nepomuk stores the information of the mail. The Nepomuk project is no longer maintained in KDE since 4.13. For email indexing, Baloo provided an Akonadi resource to index emails, contacts and events. Tags are now maintained by Akonadi itself. |