I am seeing a problem with FltGetFileNameInformation on Windows 7. I attempt to get the file name when the SearchIndexer is opening the file by ID (see stack below). In
pre-create I make the following call:
The most common thing where FltGetFileNameInformation returns STATUS_INVALID_PARAMETER is calling with the third parameter NULL. That’s not the case here however…
Unfortunately the stack below doesn’t help much to figure out what went wrong at that time… COuld you please run this on a checked build with verifier enabled for both filter manager and your minifilter, maybe something will show up ?
The only other thing I can think of is that if this happens only with the SearchIndexer, maybe it has something to do with oplocks. Did you try to see if the code works with defrag (which uses opens by ID but no oplocks as far as i know)?
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
When I run defrag it fails but with STATUS_ACCESS_DENIED rather than STATUS_INVALID_PARAMETER.
I can try to install a checked build of Windows 7 but I use a VM to debug with and I have not been able to get any checked build installed as a VM (VmWare) so far.
Since you are doing the name normalization in the context of the issuing thread and it is possible that it doesn’t have traverse privileges, you might get STATUS_ACCESS_DENIED for open-by-ID creates.
Quote from MSDN:
If the user opened the file by file ID but does not have traverse privileges for the entire path, FltGetFileNameInformation fails with this return value.
STATUS_ACCESS_DENIED is an error code.
Could you try something like querying on a different thread with traverse privileges or adding traverse privileges to the current thread (which is probably not a good idea in a product, but should be fine for testing only…) ? I would check if this works with SearchIndexer as well, just to make sure.
Would it be possible to query the name in postCreate for files opened by ID ? Not sure what the architecture of the application is but from a performance perspective this would be slightly better.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
There are some cases where I need to have the name in post-create when the create failed. This is why I am getting the name in pre-create now. I may be able to massage to code to handle open by ID as a special case but it would be much better if getting the name in pre-create would work in this case.
I will try adding the traverse privilege when I get some time - it is not the highest priority for me right at the moment.
Another problem with getting the name in post-create has do do with redirection (like the simrep example). How can you redirect an open by ID if you cannot get the name in pre-create?
As I said before I’m not familiar with the architecture of your filter. There are filters where the name query can be performed in postCreate without any issues while this is not an option for others. If it works for you, then you get some perf back.
Simrep has numerous other issues, it was not intended as a working minifilter sample but rather as an example on how to return STATUS_REPARSE and how to use IoReplaceFileObjectName. Redirecting an open-by-ID might lead to many other issues, beyond the scope of SimRep.
On an unrelated note, we are constantly trying to figure out which approach to take. Should we write samples that are complete and that work well in all possible cases (which are basically products) or samples that just showcase some particular feature or behavior of the system, but do not handle all the possible cases ? The first approach has some major drawbacks: the code can become very complex and the message might get distorted while also requiring a lot of resources which means we would release such a sample every couple of years (not to mention what releasing what amounts to full product source code would do to the community). The second approach needs a lot less resources and might make things clear, but people that study it will undoubtedly find the problems that it doesn’t address.
It is clear to me that either choice will upset someone. We receive mails that complain either that fastfat is too complicated and it isn’t clear from it which things are important or that the samples are too simple and they never show any of the really hard stuff.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.