[Nepomuk] Re: incorrect search results after file modifications

[Vishesh Handa]

Hey John

Sorry, about the late reply. We Nepomuk developers have been kinda out of it
lately. :)

On Fri, Apr 15, 2011 at 11:15 AM, john terragon <terragonjohn at yahoo.com>wrote:

> Hi.
> I've activated kde desktop search and nepomuk for the first time with the
> 4.6.1 release but I'm having some problems with the correctness of the searc
> results. As a quick try, I set the indexable folders to a couple of them
> containing about 3500 files and 300 subdirs. After the initial indexing this
> is what I get:
>
> 1) If I create, from console, a new file "strange_name.txt" containing a
> single word strange_word_1, then apparently it is immediately indexed by
> nepomuk and searching either for name or content with dolphin I get the
> correct file.
>
> 2) If I modify "strange_name.txt" _from_console_ changing strange_word_1
> with strange_word_2, then searching for "strange_word_2" with dolphin I
> don't get any result and I still get "strange_name.txt" if I look for
> "strange_word_1". Not only it does not appear to update the index
> immediately but even after hours still no results for strange_word_2.
>
> 3) If I modify "strange_name.txt" as in 2) but with a kde apps (kwrite)
> then I get "strange_name.txt" as a result of searching for content with
> "strange_word_2" BUT I still get "strange_name.txt" if i search for
> "strange_word_1" (which is not there anymore). And this is generalized: if I
> do n changes with "strange_word_1",...."strange_word_n" I will still get
> "strange_name.txt" no matter which one of the strange_word I use to search.
>

Confirmed! This is weird.

It seems to be some kind of inotify problem. The File watching service
doesn't seem to be always sending the required signals. :/ The semi good
news is that I think I'll be able to write a test case for the exact steps
you've described. I'll let you know what happens.


>
> Even though I'm just indexing 3500 files I increased the max_user_watches
> to 524288, as described in
> I read that blog post
> http://www.afiestas.org/nepomuk-is-not-fast-is-instant/  (hoping that such
> an high number would induce nepomuk to put an inotify watch for each file
> indexed) but the results are still the same.
>
> Is this supposed to happen? Is it a known bug? Because performances with
> virtuoso are not bad (besides some crashes during the scanning) but the
> correctness of the searches after changes in the files is a big problem, for
> me at least.
>

The crashes were probably caused by faulty Strigi plugins. We'll have to
introduce some kind of multi-process architecture, so that the indexing does
not stop if one of the strigi plugins crashes.


>
> I'm using debian unstable with the 4.6.1 (semi)-official kde packages from
> http://qt-kde.debian.net/.
>
> Best
> john
>
>
>
>
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20110429/18e9ad7d/attachment.htm