On Tue, 22 Nov 2011 21:22:06 +0530, Duncan <1i5t5.duncan@xxxxxxx> 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.
