G
Guest
I read often hereabouts that the index does not update in real time, to which
the obvious question is: why not?
The indexer receives notifications of events that relate to finding & use
(such as create and delete - I don't know what the whole list is...) so it
seems to me logical that it should cache recent events.
Searches for files should be masked with the results the cache: if the main
index says the file exists but the cache says it doesn't then don't show that
result; if a file is moved then redirect the result to the new location using
the cache; etc. etc.; if the file is only in the cache then... well, there's
no conflict with the main index. (NB I do hope that when a file is moved the
Indexer doesn't delete and rebuild for that file - I hope it's clever enough
to save that effort...)
As for the cache itself... well, if indexing responds to various events at
some later time, it must be keeping a record of them somewhere.
Now, I can appreciate that users create few files manually, but can delete
very large numbers - and could create very large numbers programmatically.
It would therefore make sense to separate file attributes from content as
far indexing and searching is concerned - to a certain degree... you could
separate search results for new files based on basic OS attributes only from
searches based on the content of those files (highlight them the way new apps
get highlighted after install?)
No one can reasonably expect an arbitrarily large amount of data to be
indexed by content in an arbitrarily short space of time - but if the file
can be created/deleted/moved and not lost in the process one can reasonably
expect the Search function to know about basic attributes such as the
filename at the very least..
And with regard to indexing removable media, if the medium is r/w why not
store the index on the medium - space/bandwidth permitting. You could even
give the user the choice:... no index, index of filenames only, full index,
etc. especially since at the filename only level it surely wouldn't take too
long compared to the time to update the directory anyway - would it?
[And BTW - since searching for shortcuts produces oddities... what does the
Save Shortcut Properties indexing filter do?]
I'd be interested to know more about how and why it works (gremlins and
their offspring excepted) ... and other user's opinions.
Julian
the obvious question is: why not?
The indexer receives notifications of events that relate to finding & use
(such as create and delete - I don't know what the whole list is...) so it
seems to me logical that it should cache recent events.
Searches for files should be masked with the results the cache: if the main
index says the file exists but the cache says it doesn't then don't show that
result; if a file is moved then redirect the result to the new location using
the cache; etc. etc.; if the file is only in the cache then... well, there's
no conflict with the main index. (NB I do hope that when a file is moved the
Indexer doesn't delete and rebuild for that file - I hope it's clever enough
to save that effort...)
As for the cache itself... well, if indexing responds to various events at
some later time, it must be keeping a record of them somewhere.
Now, I can appreciate that users create few files manually, but can delete
very large numbers - and could create very large numbers programmatically.
It would therefore make sense to separate file attributes from content as
far indexing and searching is concerned - to a certain degree... you could
separate search results for new files based on basic OS attributes only from
searches based on the content of those files (highlight them the way new apps
get highlighted after install?)
No one can reasonably expect an arbitrarily large amount of data to be
indexed by content in an arbitrarily short space of time - but if the file
can be created/deleted/moved and not lost in the process one can reasonably
expect the Search function to know about basic attributes such as the
filename at the very least..
And with regard to indexing removable media, if the medium is r/w why not
store the index on the medium - space/bandwidth permitting. You could even
give the user the choice:... no index, index of filenames only, full index,
etc. especially since at the filename only level it surely wouldn't take too
long compared to the time to update the directory anyway - would it?
[And BTW - since searching for shortcuts produces oddities... what does the
Save Shortcut Properties indexing filter do?]
I'd be interested to know more about how and why it works (gremlins and
their offspring excepted) ... and other user's opinions.
Julian