[Nepomuk] Bugs, Patches and Scripts. - StrigiService & KInotify

[Vishesh Handa]

Hello Sebastian


> While conceptually you are completely right I think it would be better
> to make the FileWatcher update the strigi config. FileWatcher is taking
> enough resources as it is by watching all the folders.
>

I tried that, but then I required the StrigiServiceConfig class. So, I
thought KInotify is more portable. But we don't want another resource hog!

I thought about doing it this way, too. But then twice the mem is used
> and I figured watchingPath() and removePath() are not called very often.
> Thus, the mem savings would be preferable. I suppose...
>

The memory saved wouldn't be much. But, watchingPath() is only called in
FileWatch::addWatch before adding a watch. The moment I see a TODO:
Optimize. I just have to try! :)


> Why do you think it should do this? After all, addWatch does also
> recurse into subdirs. Plus, we only stop watching a folder if it is
> removed. In that case the subfolders are of no interest anyway. :P
>
> True. But it doesn't seem logical. It serves the FileWatcher's purpose
perfectly, but logically one would think removeWatch would just remove 1
watch. Plus, who in the world would be watching a subdir when they are
already watching it's parent. Maybe we could add another function which
removes the other watches?


> Only sibling? AFAIK the only problem is moving to a non-watched folder,
> i.e. a folder outside the home dir or any indexed folder.
>

Yes. And my code only watches the indexed directories first parent (cd ..).
Hence the sibling thing. It was just the first patch where I was fiddling
around.

Btw, we need to do something about this. I have partitioned my hard disk,
and they are mounted in the /media/ directory. The metadata mover just
deletes the metadata. I was thinking about downloading the kernel's source
code, and try to hack inotify, but then I've just compiled my kernel once in
my life, and making modifications seems like a huge leap forward. :(

Thus, it can be simplified a lot by removing all the dirwatch details
> and just keeping the slotMoved method. So in the end it is just one
> method. Maybe no need for a class. :P
>

I was mainly using this class for testing kinotify, I just changed the name
and slapped on a couple of functions. I thought it wouldn't be right for me
to just state the problem without even trying to solve it.


> but I will see about making that public so we can collaborate. :)
>
> Please do. Trying to debug the strigiservice while filewatch keeps spewing
out debug messages is quite, well not difficult, but distracting.


So, what do we do now? Should I try to integrate it into the filewatch
service?

- Vishesh Handa

PS : I got an SVN account! :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100426/19d0b04e/attachment-0001.htm