Get filename in minifilter

NTFSD
1

FltGetFileNameInformation ( normalized or opened ) can not resolve some filenames like a $LogFile or $Mft.
I’m trying to get them in minispy filter from an DDK samples. Is there other way? Procmon can see them in the own minifilter.

–
Pavel Sokolov

2

> FltGetFileNameInformation ( normalized or opened ) can not resolve some filenames like a $LogFile or $Mft.

I’m trying to get them in minispy filter from an DDK samples. Is there other way? Procmon can see them in the own minifilter.

I receive STATUS_FLT_INVALID_NAME_REQUEST and STATUS_FLT_NAME_CACHE_MISS in FltGetFileNameInformation.
But is there any other way to get the name from FLT_CALLBACK_DATA ?

–
Pavel Sokolov

3

> I receive STATUS_FLT_INVALID_NAME_REQUEST and STATUS_FLT_NAME_CACHE_MISS in FltGetFileNameInformation.

But is there any other way to get the name from FLT_CALLBACK_DATA ?

I found it.

–
Pavel Sokolov

4

Could you post the solution you have found ?

2011/2/12 Pavel Sokolov

> I receive STATUS_FLT_INVALID_NAME_REQUEST and STATUS_FLT_NAME_CACHE_MISS in
>> FltGetFileNameInformation.
>> But is there any other way to get the name from FLT_CALLBACK_DATA ?
>>
>
> I found it.
>
>
> –
> Pavel Sokolov
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

5

Name is here: FltObjects->FileObject->FileName

–
Pavel Sokolov

“ooyala” wrote in message news:xxxxx@ntfsd…
Could you post the solution you have found ?

2011/2/12 Pavel Sokolov

I receive STATUS_FLT_INVALID_NAME_REQUEST and STATUS_FLT_NAME_CACHE_MISS in FltGetFileNameInformation.
But is there any other way to get the name from FLT_CALLBACK_DATA ?

I found it.

6

technically you should cache it at pre-create and used the cached name in other callbacks.

7

> technically you should cache it at pre-create and used the cached name in other callbacks.

I found note in the minifilter source that using cache is not recommended in the release.

–
Pavel Sokolov

8

No I did not meant that. By cache I meant that get the name from file object create a per stream context and store the name into it. Later use it from context.

9

> No I did not meant that. By cache I meant that get the name from file object create a per stream context and store the name

into it. Later use it from context.

I don’t need it because I send filenames to usermode app.

–
Pavel Sokolov

10

You should use the FltGetFileNameinformation function in minifilters instead
of building it from the FILE_OBJECT.

Thanks,
Alex.

11

@Alex

>You should use the FltGetFileNameinformation function in minifilters instead of building it from the FILE_OBJECT.

May be I am missing something on it, let me ask something to clarify it.

A filter which changes fileName (logical to physical) in pre-create; You will obviously “have to” store it in some context in pre-create if you want logical name.

A filter which does not modify fileName; You can cache it or use the FltGetFileNameinformation API.

I see caching it as an optimization as most of the callbacks retrieves the context for their processing. So saving and getting the name from cache will be faster than calling an API.( I know its cached in FltMgr as well). Now if some one below us is changing the file name, than my filter we’ll not see that name, if it caches it from FO; but the name passed by layer above me.

So if I do not care about actual name processed by FS, I *can* use name from FO else I should use the API.

Thanks
Aditya

12

Hi Aditya,

In my experience, changing the name in preCreate is usually done by
returning STATUS_REPARSE for which case this discussion doesn’t apply (the
new IRP_MJ_CREATE will have the same name both in pre and postCreate after
the reparse). I don’t know of any filter that changes the name in the
FILE_OBJECT and while it is possible (as a friend used to say, it’s software
so anything is possible given enough resources) it is complicated by other
things (such as proper reference counting in cases where there is a
RelatedFileObject ; there may be more, I’ve never actually tried it).

If you own the FO (if you complete the IRP_MJ_CREATE request) then indeed
you can store the name in your context. In this case you are taking on
responsibility for the FO the way a file system would and so you will see
all requests and in fact your cache is no longer a cache but rather the
authority that knows that FO’s name (so you can’t be out of sync because
there is nothing to be in sync with in the first place).

However, if you pass the IRP_MJ_CREATE on to a layer below yours (regardless
of whether you change the name in the FO or not) then unless you filter all
operations that might result in a change to the path to the file you risk
your cache being inconsistent with the file system. FltMgr’s name cache code
addresses these cases already and there are quite a few cases to worry
about. I’m listing just a few things you’d need to worry about as an example
(but there are more, a lot of the code in FltMgr is dedicated to building
and caching names):

  1. someone renames any directory on the volume (if that directory was in the
    path to your file then the name might not be valid and you need to update
    the path). Not only directory renames, but consider the case of setting a
    short name on a directory for example.
  2. hardlinks also complicate things a bit. You might need to cache the name
    not at an SCB level but at FO level.
  3. renames are, as usual, particularly tricky. What if there are 3 renames
    sent down for your file (file A) , one that renames File A to File B, one
    that renames File B to File C and one that renames File C to File A. If you
    don’t serialize them you don’t know the order and you no longer know the
    name of your file in the file system.
  4. transactions… I’ll leave it at that :).

Also, there is one more benefit to using FltMgr’s cache (other than the fact
that it caches your name), which is that it is shared between minifilters so
it doesn’t only improves your processing time but it might improve overall
system performance.

However, your point is correct. If you don’t care about the name at FS level
then you can indeed cache it yourself. I wrote a blog post at some point
about why filters and names which might be relevant to the discussion
(http://fsfilters.blogspot.com/2010/02/names-and-file-systems-filters.html).

Does this answer your question ?

Thanks,
Alex.

13

>>Does this answer your question ?

100% (as expected :))