<b>This patch doesn't work perfectly.</b><br><br>I seem to to be duplicating code from StrigiServiceConfig, which is not something I'm too happy about. <br><br>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.<br>
<br>:-/<br><br>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). <br>
This method will ultimately result in what we want except when then this happens -<br>1. The user moves some folder which is being indexed.<br>2. The metadata mover is active.<br>3. He edits the files being watched via kcm.<br>
4. The metadata mover becomes idle.<br><br>There is one more issue. Say I have an indexed folder <b>Boo</b>, and it has a sub-folder <b>Yoda</b>. 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?<br>