Since so much MSN Desktop Search discussion and Wiki is here... I'm trying to write an ifilter for a filetype that doesn't have an extension, presumably because it comes from the *nix world. I haven't figured out how to associate the ifilter with the filetype; no extension means no class to be associated to.
One competiting product simply uses the LOCATION of the files. This would be an okay option, but iFilters don't seem to work that way - that is, indexer service won't call my ifilter on a directory or call me and let my ifilter iterate through the files it considers appropriate.
Another competing product simply provides a hook for data from the primary application. This isn't quite as good because it moves the filtering to the app rather than the index service, but at least it solves the problem.
IPersistFile::GetCurFile() could be used to return the file my filter believes it's on, but I'm not sure the Indexer asks for or would respect that, plus I can't necessarily get my ifilter called in the first place.
So likely solutions (and I'm hoping at least one is an option) are:
1. Bind the ifilter to a directory and all files inside it
2. Bind it to files without extensions and let it decide if it can handle it, passing control back to the next filter in line if not
3. Bind it to the indexer start up or to scheduled indexing, with the ifilter having the duty of reporting the files it wishes to report Chunk/Text/Value data on
4. Let the ifilter be called by another call to a hook in the indexer service, telling the index service to start querying the ifilter on a specific list of files.
Are any of these possible? Or are ifilters inherently incapable of dealing with data that has conflicting or no extensions?
Thanks