file indexing under KDE 4.7.3

[phanisvara das]

On Tue, 22 Nov 2011 21:22:06 +0530, Duncan <1i5t5.duncan at cox.net> wrote:

> Thomas Olsen posted on Tue, 22 Nov 2011 09:50:03 +0100 as excerpted:
>
>> On Tuesday 22 November 2011 14:12 phanisvara das wrote:
>>> i noticed since KDE 4.7.3 that file indexing, after the initial index
>>> of all files specified in strigi configuration has finished, remains
>>> suspended on each log in. un-suspending seems to cause all files to be
>>> re-indexed.
>>>
>>> i'm wondering if changes to the indexed files, or addition of new ones
>>> into the indexed folders, will get picked up by some nepomuk daemon
>>> while indexing remains suspended, or if i'm supposed to un-suspend it
>>> now & then to keep the index up-to-date?
>>
>> Here - also on 4.7.3 - it wakes up from idle and indexes new/changed
>> files. And it has stopped re-indexing my music collection all the time.
>> Unfortunately it has also stopped working from krunner, so it's not
>> really that useful...
>
> FWIW, I rebuilt all of kde (well, the packages with the option) without
> semantic-desktop at all, here on gentoo, shortly after 4.7.0 came out,
> when I removed all kdepim components and akonadi, and thus could do so.
> So all that stuff's not only diabled so it doesn't run, it's build-time
> disabled and thus not installed at all, on my system! =:^)
>
> However, based on the changelogs for 4.7 and the continued improvements
> in 4.7.3, I believe once it's done indexing (or checking that its index
> is still current after the initial indexing), it now turns on fanotify or
> whatever similar kernel-level filesystem monitoring, and thus knows when
> a file changes so it can reindex it.
>
> ... Assuming the required kernel config option is enabled in the kernel
> you're running, of course.
>


after the initial index finishes an announcement is shown to that effect,  
and from then on it remains suspended. i also believe that nepomuk is  
monitoring file changes to keep things up-to-date, but haven't seen an  
explanation of that in any blog or mailing list post yet; was hoping to  
find here somebody who actually knows.

moreover, after the initial index finished i un-suspended file indexing  
manually, and nepomuk/strigi apparently did find new areas (directories)  
that are also within the specified search area, but haven't been indexed  
during the first run, adding a couple hundred files to the search index  
and MB to the nepomuk data store -- which probably wouldn't have happened  
if i hadn't un-suspended file indexing manually.

seems file indexing is being suspended as soon as possible to prevent  
people from complaining that nepomuk eats all their CPU cycles. perhaps  
that still needs some work, to manage nepomuk's re-emergence once in a  
while to make sure it got everything indexed it's supposed to.

-- 
phani.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.