omindex needs to notice deleted files

[Olly Betts]

(Condensed from a dicussion with Richard Boulton)

omindex currently works by scanning the filing system, but it doesn't compare it to what's in the DB. So added and changed files are spotted but deleted files hang around in the DB forever at their last indexed version.

The current architecture isn't right really - it needs to either keep the FS path, or map URL back to FS path and dump all those out into an STL set<> (say) before it starts then tick off the ones it has seen. Then at the end remove any left in the set. They're either deleted files, or files that the mappings have changed for.

However currently you'd run omindex twice for two fs->url mappings - that needs to be fixed to be one run with a mappings file or similar to specify them.

If the STL set<> would be too big we might be able to do this a directory at a time, keeping track of any directories not found by recursion and removing any documents that are in them.

Or perhaps index each file by all the directories above it, and spot the missing directories that way?

Perhaps all this filename tracking should be in a separate DB as it's probably just bloat when searching...

[Olly Betts]

Fixed in CVS (in a much simpler way)

[Olly Betts]

Fixed in 0.8.2