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! :)
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
