Damn, this is a tricky one. How about a hacky solution: the file watch service does not update the config but writes a log of moved and watched folders. This log can be read by strigi after or before updating the index and then it can update its config itself without triggering a re-index.
Or the most generic solution: have a nepomuk configuration service which has dbus methods to update all nepomuk config things. This service could then decide if it is necessary for strigi to re-index. Brainstorming.... Cheers, Sebastian On 04/30/2010 02:07 PM, Vishesh Handa wrote: > *This patch doesn't work perfectly.* > > I seem to to be duplicating code from StrigiServiceConfig, which is not > something I'm too happy about. > > The moment some watched folder is moved/renamed, metadata mover fires > up, and starts moving the metadata. Meanwhile the strigi config file is > updated and the strigi service detects that the file has been changed > (exact same code as in the testpatch) and then proceeds to delete > unnecessary metadata via removeOldAndUnwantedEntries(). Which removes > some of the indexed data. And since some of the metadata has been > removed the filewatch service can't move it. After that the strigi > service proceeds to index the moved files who's metadata isn't intact. > > :-/ > > It's doing what we want, but not how we want it. We need to delay > writing to the config file until the metadata mover has finished is job. > I could just slap on a signal which is fired when it changes from a Busy > to Idle state (and that'll work) but for all you know the user could be > performing other tasks and the metadata mover doesn't become idle for a > long time. (Maybe he's monitoring a network drive where other users are > doing stuff). > This method will ultimately result in what we want except when then this > happens - > 1. The user moves some folder which is being indexed. > 2. The metadata mover is active. > 3. He edits the files being watched via kcm. > 4. The metadata mover becomes idle. > > There is one more issue. Say I have an indexed folder *Boo*, and it has > a sub-folder *Yoda*. Yoda is moved somewhere outside Boo which isn't > being indexed. Should Yoda still be indexed? Or Not? I think it should > be. What do you think? _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
