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

[Sebastian Trüg]

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?