0

I have a task to implement service with behavior like this one. My question is:

How Indexing Service remember what files was already indexed and what no, what files changed and need to reindex them?

Also, I can stop this service and then start it after a few days, it continues to work. Does it have its own database with information about files?

Thank you

skaffman
  • 398,947
  • 96
  • 818
  • 769
ZedZip
  • 5,794
  • 15
  • 66
  • 119

1 Answers1

1

Usually the indexing-service stays in the background using WaitForSingleObject / WaitForMultipleObjects on Handles created by calls to FindFirstChangeNotification. If you want to support that the indexing service can be shut down (or be used for an already existent directory) you should definitely store the timestamp of your last index run on every file. You can compare this to the LastWriteTime of the given file.

EDIT: you should use ReadDirectoryChangesW and another thread which asynchronously indexes the files to be sure to not miss any changes. You can either spawn new threads for every file to index(expensive) or use a job queue and a fixed amount of worker threads(1 or 2 preferably)

mschneider
  • 716
  • 4
  • 9
  • Ok, thnx. it seems after Stop/Start service re-scans File system and read its database to check what was changed since last activity? – ZedZip Jan 07 '11 at 11:06
  • exactly. just iterate over every file in the indexed directory and it's subdirectories and check their LastWrittenTime against the timestamp in the indexers database. – mschneider Jan 07 '11 at 11:14
  • Btw, how it works if a lot of files are changed, added simultaneously? is it possible that part of notifications can be lost for the service? in this case it does not know that indexes are not actual... – ZedZip Jan 07 '11 at 11:56
  • You could handle the change notifications by queuing the filenames to a thread safe job queue, which is processed asynchronously. So that you can start waiting for the next change as soon as possible. – mschneider Jan 07 '11 at 12:57