FltGetFileNameInformation() after cleanup

NTFSD
1

I am creating a mini-filter driver. As a part of functionality I need to
obtain the full file name and (surprise! surprise!) use
FltGetFileNameInformation() for this.

The problem is that on WinXPsp2 platform on a post-Cleanup stage
(FILE_OBJECT already has FO_CLEANUP_COMPLETE flag set) the call returns:
STATUS_FLT_NAME_CACHE_MISS error, if the query method flag is
FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP and
STATUS_FLT_INVALID_NAME_REQUEST error, if the query method flag is
FLT_FILE_NAME_QUERY_FILESYSTEM_ONLY.
The method returns the file information in other cases, like on
pre-Cleanup stage.

It looks like cleanup IRP “cleans up” the file name cache and it is
considered incorrect (at this time?) to call the file system.
Does anybody else see the same behavior?

If I “manually” issue a request to FS (FltAllocateCallbackData() -> set
IRP_MJ_QUERY_INFORMATION + FileNameInformation ->
FltPerformSynchronousIo() -> FltFreeCallbackData()) then I receive the file
name without any errors even if FILE_OBJECT already has FO_CLEANUP_COMPLETE
flag set.
Is it safe to use this procedure in case FltGetFileNameInformation()
fails?

Just for information. According to Windows Driver Kit documentation
(v5256) FltGetFileNameInformation() may return
STATUS_FLT_INVALID_NAME_REQUEST in the following conditions:

  1. FltGetFileNameInformation cannot get file name information if the
    TopLevelIrp field of the current thread is not NULL, because the resulting
    file system recursion could cause deadlocks or stack overflows.
  2. FltGetFileNameInformation cannot get file name information in the
    paging I/O path.
  3. FltGetFileNameInformation cannot get file name information in the
    post-close path.
  4. FltGetFileNameInformation cannot get the short name of a file in the
    pre-create path.

That’s OK, I check for these conditions before making the call.

Any help or suggestion will be greatly appreciated.

2

Hmm, I dont know, this might not be relevant, but sometimes (often)
completion of IRP_MJ_CLEANUP happens after completion of IRP_MJ_CLOSE -
perhaps filesystem dereferences the FileObject so ObjectManager sends
IRP_MJ_CLOSE - so the close is sort of nested inside the cleanup.

“Alex Gladkiy” wrote in message news:xxxxx@ntfsd…
> I am creating a mini-filter driver. As a part of functionality I need to
> obtain the full file name and (surprise! surprise!) use
> FltGetFileNameInformation() for this.
>
> The problem is that on WinXPsp2 platform on a post-Cleanup stage
> (FILE_OBJECT already has FO_CLEANUP_COMPLETE flag set) the call returns:
> STATUS_FLT_NAME_CACHE_MISS error, if the query method flag is
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP and
> STATUS_FLT_INVALID_NAME_REQUEST error, if the query method flag is
> FLT_FILE_NAME_QUERY_FILESYSTEM_ONLY.
> The method returns the file information in other cases, like on
> pre-Cleanup stage.
>
> It looks like cleanup IRP “cleans up” the file name cache and it is
> considered incorrect (at this time?) to call the file system.
> Does anybody else see the same behavior?
>
> If I “manually” issue a request to FS (FltAllocateCallbackData() -> set
> IRP_MJ_QUERY_INFORMATION + FileNameInformation ->
> FltPerformSynchronousIo() -> FltFreeCallbackData()) then I receive the
> file name without any errors even if FILE_OBJECT already has
> FO_CLEANUP_COMPLETE flag set.
> Is it safe to use this procedure in case FltGetFileNameInformation()
> fails?
>
> Just for information. According to Windows Driver Kit documentation
> (v5256) FltGetFileNameInformation() may return
> STATUS_FLT_INVALID_NAME_REQUEST in the following conditions:
>
> 1. FltGetFileNameInformation cannot get file name information if the
> TopLevelIrp field of the current thread is not NULL, because the resulting
> file system recursion could cause deadlocks or stack overflows.
> 2. FltGetFileNameInformation cannot get file name information in the
> paging I/O path.
> 3. FltGetFileNameInformation cannot get file name information in the
> post-close path.
> 4. FltGetFileNameInformation cannot get the short name of a file in the
> pre-create path.
>
> That’s OK, I check for these conditions before making the call.
>
> Any help or suggestion will be greatly appreciated.
>
>

3

I find that if I need the filename for post-Cleanup processing, it best
to query it in your pre-Cleanup handler and pass it forward to your
completion routine. I also seem to recall that ntfs has been known to
“free” filename information in its cleanup processing.

/ted

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alex Gladkiy
Sent: Monday, April 24, 2006 10:28 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation() after cleanup

I am creating a mini-filter driver. As a part of functionality I need
to
obtain the full file name and (surprise! surprise!) use
FltGetFileNameInformation() for this.

The problem is that on WinXPsp2 platform on a post-Cleanup stage
(FILE_OBJECT already has FO_CLEANUP_COMPLETE flag set) the call returns:
STATUS_FLT_NAME_CACHE_MISS error, if the query method flag is
FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP and
STATUS_FLT_INVALID_NAME_REQUEST error, if the query method flag is
FLT_FILE_NAME_QUERY_FILESYSTEM_ONLY.
The method returns the file information in other cases, like on
pre-Cleanup stage.

It looks like cleanup IRP “cleans up” the file name cache and it is
considered incorrect (at this time?) to call the file system.
Does anybody else see the same behavior?

If I “manually” issue a request to FS (FltAllocateCallbackData() ->
set
IRP_MJ_QUERY_INFORMATION + FileNameInformation ->
FltPerformSynchronousIo() -> FltFreeCallbackData()) then I receive the
file
name without any errors even if FILE_OBJECT already has
FO_CLEANUP_COMPLETE
flag set.
Is it safe to use this procedure in case FltGetFileNameInformation()
fails?

Just for information. According to Windows Driver Kit documentation
(v5256) FltGetFileNameInformation() may return
STATUS_FLT_INVALID_NAME_REQUEST in the following conditions:

  1. FltGetFileNameInformation cannot get file name information if the
    TopLevelIrp field of the current thread is not NULL, because the
    resulting
    file system recursion could cause deadlocks or stack overflows.
  2. FltGetFileNameInformation cannot get file name information in the
    paging I/O path.
  3. FltGetFileNameInformation cannot get file name information in the
    post-close path.
  4. FltGetFileNameInformation cannot get the short name of a file in
    the
    pre-create path.

That’s OK, I check for these conditions before making the call.

Any help or suggestion will be greatly appreciated.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@ironmountain.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

The information contained in this email message and its attachments
is intended only for the private and confidential use of the
recipient(s) named above, unless the sender expressly agrees
otherwise.
Transmission of email over the Internet is not a secure
communications medium. If you are requesting or have requested the
transmittal of personal data, as defined in applicable privacy laws
by means of email or in an attachment to email, you must select a
more secure alternate means of transmittal that supports your
obligations to protect such personal data.
If the reader of this message is not the intended recipient and/or
you have received this email in error, you must take no action
based on the information in this email and you are hereby notified
that any dissemination, misuse or copying or disclosure of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by email and
delete the original message.

4

Thanks Lyndon and Ted for you’re quickly replies!

We checked the cases you suggested - IRP_MJ_CLOSE didn’t come and result
on the Fat32 is the same.

We cannot explain very simple effect: we open some file with two apps
twice. Let the first app close the file, FltGetFileNameInformation() will
return the error STATUS_FLT_NAME_CACHE_MISS in minifilter’s post-cleanup
callback. At that time second app continue working with the file and on
every minifilter callback we call FltGetFileNameInformation() (for testing
purposes, of course) and it returns success.

What is the role of name cache?
Are there additional limitation(s) on FltGetFileNameInformation()
invocation?

Any help or suggestion will be greatly appreciated.