[kdepim-users] How to disable mail indexing with Akonadi search

[Daniel Vrátil]

On Monday, February 8, 2016 4:43:08 PM CET Martin Steigerwald wrote:
> Am Montag, 8. Februar 2016, 16:21:02 CET schrieb Martin Steigerwald:
> > Am Montag, 8. Februar 2016, 10:15:55 CET schrieb Daniel Vrátil:
> > > On Saturday, February 6, 2016 7:35:17 PM CET Martin Steigerwald wrote:
> > > > Back in Baloo times it was easy to disable mail indexing. But with
> > > > Akonadi
> > > > Search which as I understand is basically a renamed Baloo for mail
> > > > stuff
> > > > I
> > > > didn´t find a way yet. Can one disable it?
> > 
> > […]
> > 
> > > You can prevent the Indexer from starting by modifying
> > > /usr/share/akonadi/
> > > agents/akonadindexingagent.desktop, unsetting "AutoStart" capability.
> > 
> > Thank, Dan. I think that would be at the self-compiled location for me.
> > 
> > Okay, found it as akonadiindexingagent.desktop :). I didn´t find any
> > Autostart parameter in there, so I set "Autostart=false".
> 
> Okay, after I found that "Autostart=false" didn´t work to prevent the agent
> from starting, I found
> 
>  38 X-Akonadi-MimeTypes=text/directory
>  39 X-Akonadi-Capabilities=Unique,Autostart
>  40 X-Akonadi-Identifier=akonadi_indexing_agent
> 
> and removed "Autostart" from capabilities and it still autostarts.

Weird. Any chance it's finding another file, maybe from your system install? 
You probably need to restart Akonadi so that the file is read again by 
akonadi_control.


> 
> I looked a bit in the akonadi-search repo, file scheduler.cpp. And I think I
> may have a chance with
> 
>  71     //Trigger a full sync initially
>  72     if (!group.readEntry("initialIndexingDone", false)) {
>  73         qCDebug(AKONADI_INDEXER_AGENT_LOG) << "initial indexing";
>  74         QMetaObject::invokeMethod(this, "scheduleCompleteSync",
> Qt::QueuedConnection);
>  75     }
> 
> setting initialIndexDone to true in some config file. Hmmm, still baloorc!?

Historical reasons :) That's the last piece I did not migrate yet somewhere 
into Akonadi. Another junior task :)

> 
> And its set there already: initialIndexingDone=true
> 
> So I don´t get why it reindexes all the stuff again.
> 
>  61     KConfig
> config(Akonadi::ServerManager::addNamespace(QStringLiteral("baloorc")));
>  62     KConfigGroup group = config.group("Akonadi");
> 
> Okay, I at least found where it initializes a complete sync:
> 
> 130 void Scheduler::scheduleCompleteSync()
> 
> But I bet the changes to access maildir items without storing them into DB
> initially need to be done in maildir resource, not in indexing. But I can at
> least check whether it respects the "do not index" this folder setting. I
> told it to leave my biggest folders alone, yet still it hogs down my system
> like crazy.

I'd like it to be generic, so it first needs to be implemented to the client 
libraries (and ofc supported inside the server), then adapt maildir to use the 
new API/mechanism/whatever we introduce.


> Hmmm, it seems it continues with Akonadi::CollectionFetchJob which seems to
> be a method of Akonadi and I bet from there it calls into Maildir resource,
> stuffes the results into the database and then… at some expires them again.

CFJ only happens against Akonadi DB, it won't trigger communication with 
resource.

The ItemFetchJob which is then executed for each retrieved collection will 
however trigger the maildir sync - see the comment in 
FetchHelper::fetchItems() in akonadi/src/server/handler/fetchhelper.cpp.

> I think with some help I can at least get a basic understanding how it
> works. I know some C, but not C++.
> 
> Thanks,


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20160208/ce7ad7dc/attachment.sig>