FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi all,

I’m having problems with FltGetFileNameInformation() function on Windows 2003
SP1 RC.

The problem is that the function in question always returns
STATUS_FLT_INVALID_NAME_REQUEST.

According to the documentation, FltGetFileNameInformation() returns this error
if:

  1. TopLevelIrp of the current thread is not NULL
  2. in case of PAGING I/O
  3. if in post-close
  4. if in pre-create

My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE postop),
therefore cases 3) and 4) are not the culprits. As for 1 and 2, I added few
DbgPrints() to the filter, and:

  1. IoGetTopLevelIpr() is NULL
  2. (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE

I would like to know if there are other causes for the
STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?

The minifilter (and FltGetFileNameInformation()) works as expected on Windows
XP SP2.

Thanks in advance for any help regarding this issue.

Best Regards,
Mitja Horvat

Do I understand you to say you’re calling FltGetFileNameInformation() in
post-Create? You can’t do that – you must call in pre-Create and save the
results in the context.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Monday, March 21, 2005 11:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi all,

I’m having problems with FltGetFileNameInformation() function on Windows
2003
SP1 RC.

The problem is that the function in question always returns
STATUS_FLT_INVALID_NAME_REQUEST.

According to the documentation, FltGetFileNameInformation() returns this
error
if:

  1. TopLevelIrp of the current thread is not NULL
  2. in case of PAGING I/O
  3. if in post-close
  4. if in pre-create

My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE
postop),
therefore cases 3) and 4) are not the culprits. As for 1 and 2, I added few
DbgPrints() to the filter, and:

  1. IoGetTopLevelIpr() is NULL
  2. (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE

I would like to know if there are other causes for the
STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?

The minifilter (and FltGetFileNameInformation()) works as expected on
Windows
XP SP2.

Thanks in advance for any help regarding this issue.

Best Regards,
Mitja Horvat


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

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

Hi again,

there are few details I would like to add:

  • I tried using FltGetFileNameInformation() with the FLT_FILE_NAME_NORMALIZED
    and FLT_FILE_NAME_OPENED flags. I both cases it returns
    STATUS_FLT_INVALID_NAME_REQUEST.

  • I can successfully resolve the filename if I querythe device name with
    ObNameString() and append the pData->Iopb->TargetFileObject->FileName string

Regards,
Mitja Horvat

On Monday 21 of March 2005 17:58, Mitja Horvat wrote:

Hi all,

I’m having problems with FltGetFileNameInformation() function on Windows
2003 SP1 RC.

The problem is that the function in question always returns
STATUS_FLT_INVALID_NAME_REQUEST.

According to the documentation, FltGetFileNameInformation() returns this
error if:

  1. TopLevelIrp of the current thread is not NULL
  2. in case of PAGING I/O
  3. if in post-close
  4. if in pre-create

My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE
postop), therefore cases 3) and 4) are not the culprits. As for 1 and 2, I
added few DbgPrints() to the filter, and:

  1. IoGetTopLevelIpr() is NULL
  2. (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE

I would like to know if there are other causes for the
STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?

The minifilter (and FltGetFileNameInformation()) works as expected on
Windows XP SP2.

Thanks in advance for any help regarding this issue.

Best Regards,
Mitja Horvat


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

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

Oops – you can call FltGetFileNameInformation() in post-Create (although
I’ve never done it). It’s FltGetTunneledName() that is picky about where
you call it.

Sorry for the confusion.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Monday, March 21, 2005 12:06 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Do I understand you to say you’re calling FltGetFileNameInformation() in
post-Create? You can’t do that – you must call in pre-Create and save the
results in the context.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Monday, March 21, 2005 11:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi all,

I’m having problems with FltGetFileNameInformation() function on Windows
2003
SP1 RC.

The problem is that the function in question always returns
STATUS_FLT_INVALID_NAME_REQUEST.

According to the documentation, FltGetFileNameInformation() returns this
error
if:

  1. TopLevelIrp of the current thread is not NULL
  2. in case of PAGING I/O
  3. if in post-close
  4. if in pre-create

My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE
postop),
therefore cases 3) and 4) are not the culprits. As for 1 and 2, I added few
DbgPrints() to the filter, and:

  1. IoGetTopLevelIpr() is NULL
  2. (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE

I would like to know if there are other causes for the
STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?

The minifilter (and FltGetFileNameInformation()) works as expected on
Windows
XP SP2.

Thanks in advance for any help regarding this issue.

Best Regards,
Mitja Horvat


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

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


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

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

No problem :slight_smile:

Regards,
Mitja Horvat

On Monday 21 of March 2005 18:17, Ken Cross wrote:

Oops – you can call FltGetFileNameInformation() in post-Create (although
I’ve never done it). It’s FltGetTunneledName() that is picky about where
you call it.

Sorry for the confusion.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Monday, March 21, 2005 12:06 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Do I understand you to say you’re calling FltGetFileNameInformation() in
post-Create? You can’t do that – you must call in pre-Create and save the
results in the context.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Monday, March 21, 2005 11:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi all,

I’m having problems with FltGetFileNameInformation() function on Windows
2003
SP1 RC.

The problem is that the function in question always returns
STATUS_FLT_INVALID_NAME_REQUEST.

According to the documentation, FltGetFileNameInformation() returns this
error
if:

  1. TopLevelIrp of the current thread is not NULL
  2. in case of PAGING I/O
  3. if in post-close
  4. if in pre-create

My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE
postop),
therefore cases 3) and 4) are not the culprits. As for 1 and 2, I added few
DbgPrints() to the filter, and:

  1. IoGetTopLevelIpr() is NULL
  2. (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE

I would like to know if there are other causes for the
STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?

The minifilter (and FltGetFileNameInformation()) works as expected on
Windows
XP SP2.

Thanks in advance for any help regarding this issue.

Best Regards,
Mitja Horvat


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

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


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

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


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

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

Mitja,

What is the name in the TargetFileObject->FileName? Is the device a
local or remote file system? Also, what query method are you using?

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Monday, March 21, 2005 9:14 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi again,

there are few details I would like to add:

  • I tried using FltGetFileNameInformation() with the
    FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both cases it
    returns STATUS_FLT_INVALID_NAME_REQUEST.

  • I can successfully resolve the filename if I querythe device
    name with
    ObNameString() and append the pData->Iopb->TargetFileObject->FileName
    string

Regards,
Mitja Horvat

On Monday 21 of March 2005 17:58, Mitja Horvat wrote:

Hi all,

I’m having problems with FltGetFileNameInformation() function on
Windows
2003 SP1 RC.

The problem is that the function in question always returns
STATUS_FLT_INVALID_NAME_REQUEST.

According to the documentation, FltGetFileNameInformation() returns
this error if:

  1. TopLevelIrp of the current thread is not NULL
  2. in case of PAGING I/O
  3. if in post-close
  4. if in pre-create

My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE
postop), therefore cases 3) and 4) are not the culprits. As for 1 and
2, I added few DbgPrints() to the filter, and:

  1. IoGetTopLevelIpr() is NULL
  2. (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE

I would like to know if there are other causes for the
STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?

The minifilter (and FltGetFileNameInformation()) works as expected on
Windows XP SP2.

Thanks in advance for any help regarding this issue.

Best Regards,
Mitja Horvat


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

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


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

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

Hi Molly,

the device is the local C: drive while the filename is c:\tmp\bla.txt.

Process Accessing File: cmd.exe
Device Object: \Device\HarddiskVolume1
pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
pRelatedObject->FileObject->FileName = “\tmp\bla.txt”

I tried using all 4 query methods with the same result (default, cache only,
filesystem only and always allow cache lookup).

After investigating this issue further, I found out that the error is not
returned for every file, but for files with Reparse Points. The reason
FltGetFileNameInformation() fails every time is that I call this function
only for files with specific reparse point tags. This is also the reason I’m
calling FltGetFileNameInformation() in the POST-create. Could reparse points
be the problem?

Thank you for your help on this issue,

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 02:24, Molly Brown wrote:

Mitja,

What is the name in the TargetFileObject->FileName? Is the device a
local or remote file system? Also, what query method are you using?

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Monday, March 21, 2005 9:14 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi again,

there are few details I would like to add:

  • I tried using FltGetFileNameInformation() with the
    FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both cases it
    returns STATUS_FLT_INVALID_NAME_REQUEST.

  • I can successfully resolve the filename if I querythe device
    name with
    ObNameString() and append the pData->Iopb->TargetFileObject->FileName
    string

Regards,
Mitja Horvat

On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> Hi all,
>
> I’m having problems with FltGetFileNameInformation() function on
> Windows
> 2003 SP1 RC.
>
> The problem is that the function in question always returns
> STATUS_FLT_INVALID_NAME_REQUEST.
>
> According to the documentation, FltGetFileNameInformation() returns
> this error if:
> 1) TopLevelIrp of the current thread is not NULL
> 2) in case of PAGING I/O
> 3) if in post-close
> 4) if in pre-create
>
> My minifilter driver hooks to the post-create callback (IRP_MJ_CREATE
> postop), therefore cases 3) and 4) are not the culprits. As for 1 and
> 2, I added few DbgPrints() to the filter, and:
>
> 1) IoGetTopLevelIpr() is NULL
> 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
>
> I would like to know if there are other causes for the
> STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known bug?
>
> The minifilter (and FltGetFileNameInformation()) works as expected on
> Windows XP SP2.
>
> Thanks in advance for any help regarding this issue.
>
> Best Regards,
> Mitja Horvat
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@hermes.si To
> unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Yes, it is because of the reparse point that you are getting this error.

After the CREATE has been sent to the file system, it is no longer safe
to build the name from the FileObject->RelatedFileObject and
FileObject->FileName fields, so Filter Manager must query the file
system for the name. If STATUS_REPARSE is returned, the file object
returned from this CREATE was not successfully initialized by the file
system, therefore, Filter Manager cannot query the file system for the
name.

If you monitor the volume that will succeed the CREATE, you should be
able to get the name in post-CREATE then.

If you need the name for this file object, try querying the opened name
in pre-CREATE, then passing that to your post-CREATE callback. Querying
a normalized name will not work because during the normalization
process, Filter Manager will detect that the name is going to go to a
different volume and fail the FltGetFileNameInformation() call.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 3:02 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi Molly,

the device is the local C: drive while the filename is c:\tmp\bla.txt.

Process Accessing File: cmd.exe
Device Object: \Device\HarddiskVolume1
pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
pRelatedObject->FileObject->FileName = “\tmp\bla.txt”

I tried using all 4 query methods with the same result (default, cache
only, filesystem only and always allow cache lookup).

After investigating this issue further, I found out that the error is
not returned for every file, but for files with Reparse Points. The
reason
FltGetFileNameInformation() fails every time is that I call this
function only for files with specific reparse point tags. This is also
the reason I’m calling FltGetFileNameInformation() in the POST-create.
Could reparse points be the problem?

Thank you for your help on this issue,

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 02:24, Molly Brown wrote:

Mitja,

What is the name in the TargetFileObject->FileName? Is the device a
local or remote file system? Also, what query method are you using?

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Monday, March 21, 2005 9:14 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
RC

Hi again,

there are few details I would like to add:

  • I tried using FltGetFileNameInformation() with the
    FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both cases
    it returns STATUS_FLT_INVALID_NAME_REQUEST.

  • I can successfully resolve the filename if I querythe device
    name
    with
    ObNameString() and append the pData->Iopb->TargetFileObject->FileName
    string

Regards,
Mitja Horvat

On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> Hi all,
>
> I’m having problems with FltGetFileNameInformation() function on
> Windows
> 2003 SP1 RC.
>
> The problem is that the function in question always returns
> STATUS_FLT_INVALID_NAME_REQUEST.
>
> According to the documentation, FltGetFileNameInformation() returns
> this error if:
> 1) TopLevelIrp of the current thread is not NULL
> 2) in case of PAGING I/O
> 3) if in post-close
> 4) if in pre-create
>
> My minifilter driver hooks to the post-create callback
> (IRP_MJ_CREATE postop), therefore cases 3) and 4) are not the
> culprits. As for 1 and 2, I added few DbgPrints() to the filter,
and:
>
> 1) IoGetTopLevelIpr() is NULL
> 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
>
> I would like to know if there are other causes for the
> STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known
bug?
>
> The minifilter (and FltGetFileNameInformation()) works as expected
> on Windows XP SP2.
>
> Thanks in advance for any help regarding this issue.
>
> Best Regards,
> Mitja Horvat
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@hermes.si To
> unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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

Hi Molly,

thank you very much for your explanation. However, I’m curious about few
things.

After the CREATE has been sent to the file system, it is no longer safe
to build the name from the FileObject->RelatedFileObject and

Is this because the file might be redirected to another file/volume by a
reparse point? The reason I’m asking this is because I use reparse points
only as a “marking” for files - if a file has the correct reparse point tag,
the path name is resolved and sent to a user-mode application where the file
is restored. I’m wondering if it is OK to assume that
FileObject->RelatedFileObject and FileObject->FileName are valid in this
situation (the reparse point does not redirect the file to another file
object/volume).

If you need the name for this file object, try querying the opened name
in pre-CREATE, then passing that to your post-CREATE callback. Querying

I think this creates significant overhead to the minifilter. I was hoping to
do filename resolving only for files with my reparse point tags.

Your help is appreciated.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 22:07, Molly Brown wrote:

Yes, it is because of the reparse point that you are getting this error.

After the CREATE has been sent to the file system, it is no longer safe
to build the name from the FileObject->RelatedFileObject and
FileObject->FileName fields, so Filter Manager must query the file
system for the name. If STATUS_REPARSE is returned, the file object
returned from this CREATE was not successfully initialized by the file
system, therefore, Filter Manager cannot query the file system for the
name.

If you monitor the volume that will succeed the CREATE, you should be
able to get the name in post-CREATE then.

If you need the name for this file object, try querying the opened name
in pre-CREATE, then passing that to your post-CREATE callback. Querying
a normalized name will not work because during the normalization
process, Filter Manager will detect that the name is going to go to a
different volume and fail the FltGetFileNameInformation() call.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 3:02 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi Molly,

the device is the local C: drive while the filename is c:\tmp\bla.txt.

Process Accessing File: cmd.exe
Device Object: \Device\HarddiskVolume1
pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
pRelatedObject->FileObject->FileName = “\tmp\bla.txt”

I tried using all 4 query methods with the same result (default, cache
only, filesystem only and always allow cache lookup).

After investigating this issue further, I found out that the error is
not returned for every file, but for files with Reparse Points. The
reason
FltGetFileNameInformation() fails every time is that I call this
function only for files with specific reparse point tags. This is also
the reason I’m calling FltGetFileNameInformation() in the POST-create.
Could reparse points be the problem?

Thank you for your help on this issue,

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 02:24, Molly Brown wrote:
> Mitja,
>
> What is the name in the TargetFileObject->FileName? Is the device a
> local or remote file system? Also, what query method are you using?
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> Sent: Monday, March 21, 2005 9:14 AM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
> RC
>
> Hi again,
>
> there are few details I would like to add:
>
> - I tried using FltGetFileNameInformation() with the
> FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both cases
> it returns STATUS_FLT_INVALID_NAME_REQUEST.
>
> - I can successfully resolve the filename if I querythe device

name

> with
> ObNameString() and append the pData->Iopb->TargetFileObject->FileName
> string
>
> Regards,
> Mitja Horvat
>
> On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> > Hi all,
> >
> > I’m having problems with FltGetFileNameInformation() function on
> > Windows
> > 2003 SP1 RC.
> >
> > The problem is that the function in question always returns
> > STATUS_FLT_INVALID_NAME_REQUEST.
> >
> > According to the documentation, FltGetFileNameInformation() returns
> > this error if:
> > 1) TopLevelIrp of the current thread is not NULL
> > 2) in case of PAGING I/O
> > 3) if in post-close
> > 4) if in pre-create
> >
> > My minifilter driver hooks to the post-create callback
> > (IRP_MJ_CREATE postop), therefore cases 3) and 4) are not the
> > culprits. As for 1 and 2, I added few DbgPrints() to the filter,

and:
> > 1) IoGetTopLevelIpr() is NULL
> > 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
> >
> > I would like to know if there are other causes for the
> > STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known

bug?

> > The minifilter (and FltGetFileNameInformation()) works as expected
> > on Windows XP SP2.
> >
> > Thanks in advance for any help regarding this issue.
> >
> > Best Regards,
> > Mitja Horvat
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@hermes.si To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag

argument: ‘’

> To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

You cannot be guaranteed that the file system did not change the
FileObject->FileName while processing the CREATE, therefore it could not
longer have the same data in it.

The FileObject->RelatedFileObject would still be referenced in
post-CREATE, so you could do the following:
* in pre-CREATE, make a copy of FileObject->FileName and pass that to
post-CREATE
* in post-CREATE, if you see your reparse tag, use
FltGetFileNameInformation to get the name of the
FileObject->RelatedFileObject, else free your saved name buffer
* use the name returned and the buffer you safed off in pre-CREATE to
construct the name.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 1:51 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi Molly,

thank you very much for your explanation. However, I’m curious about few
things.

After the CREATE has been sent to the file system, it is no longer
safe to build the name from the FileObject->RelatedFileObject and

Is this because the file might be redirected to another file/volume by a
reparse point? The reason I’m asking this is because I use reparse
points only as a “marking” for files - if a file has the correct reparse
point tag, the path name is resolved and sent to a user-mode application
where the file is restored. I’m wondering if it is OK to assume that
FileObject->RelatedFileObject and FileObject->FileName are valid in this
situation (the reparse point does not redirect the file to another file
object/volume).

If you need the name for this file object, try querying the opened
name in pre-CREATE, then passing that to your post-CREATE callback.
Querying

I think this creates significant overhead to the minifilter. I was
hoping to do filename resolving only for files with my reparse point
tags.

Your help is appreciated.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 22:07, Molly Brown wrote:

Yes, it is because of the reparse point that you are getting this
error.

After the CREATE has been sent to the file system, it is no longer
safe to build the name from the FileObject->RelatedFileObject and
FileObject->FileName fields, so Filter Manager must query the file
system for the name. If STATUS_REPARSE is returned, the file object
returned from this CREATE was not successfully initialized by the file

system, therefore, Filter Manager cannot query the file system for the

name.

If you monitor the volume that will succeed the CREATE, you should be
able to get the name in post-CREATE then.

If you need the name for this file object, try querying the opened
name in pre-CREATE, then passing that to your post-CREATE callback.
Querying a normalized name will not work because during the
normalization process, Filter Manager will detect that the name is
going to go to a different volume and fail the
FltGetFileNameInformation() call.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 3:02 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
RC

Hi Molly,

the device is the local C: drive while the filename is c:\tmp\bla.txt.

Process Accessing File: cmd.exe
Device Object: \Device\HarddiskVolume1
pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
pRelatedObject->FileObject->FileName = “\tmp\bla.txt”

I tried using all 4 query methods with the same result (default, cache

only, filesystem only and always allow cache lookup).

After investigating this issue further, I found out that the error is
not returned for every file, but for files with Reparse Points. The
reason
FltGetFileNameInformation() fails every time is that I call this
function only for files with specific reparse point tags. This is also

the reason I’m calling FltGetFileNameInformation() in the POST-create.
Could reparse points be the problem?

Thank you for your help on this issue,

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 02:24, Molly Brown wrote:
> Mitja,
>
> What is the name in the TargetFileObject->FileName? Is the device a

> local or remote file system? Also, what query method are you using?
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> Sent: Monday, March 21, 2005 9:14 AM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1

> RC
>
> Hi again,
>
> there are few details I would like to add:
>
> - I tried using FltGetFileNameInformation() with the
> FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both
> cases it returns STATUS_FLT_INVALID_NAME_REQUEST.
>
> - I can successfully resolve the filename if I querythe device

name

> with
> ObNameString() and append the
> pData->Iopb->TargetFileObject->FileName
> string
>
> Regards,
> Mitja Horvat
>
> On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> > Hi all,
> >
> > I’m having problems with FltGetFileNameInformation() function on
> > Windows
> > 2003 SP1 RC.
> >
> > The problem is that the function in question always returns
> > STATUS_FLT_INVALID_NAME_REQUEST.
> >
> > According to the documentation, FltGetFileNameInformation()
> > returns this error if:
> > 1) TopLevelIrp of the current thread is not NULL
> > 2) in case of PAGING I/O
> > 3) if in post-close
> > 4) if in pre-create
> >
> > My minifilter driver hooks to the post-create callback
> > (IRP_MJ_CREATE postop), therefore cases 3) and 4) are not the
> > culprits. As for 1 and 2, I added few DbgPrints() to the filter,

and:
> > 1) IoGetTopLevelIpr() is NULL
> > 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
> >
> > I would like to know if there are other causes for the
> > STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known

bug?

> > The minifilter (and FltGetFileNameInformation()) works as expected

> > on Windows XP SP2.
> >
> > Thanks in advance for any help regarding this issue.
> >
> > Best Regards,
> > Mitja Horvat
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@hermes.si
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag

argument: ‘’

> To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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

Molly, thank you very much for your answer.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 23:24, Molly Brown wrote:

You cannot be guaranteed that the file system did not change the
FileObject->FileName while processing the CREATE, therefore it could not
longer have the same data in it.

The FileObject->RelatedFileObject would still be referenced in
post-CREATE, so you could do the following:
* in pre-CREATE, make a copy of FileObject->FileName and pass that to
post-CREATE
* in post-CREATE, if you see your reparse tag, use
FltGetFileNameInformation to get the name of the
FileObject->RelatedFileObject, else free your saved name buffer
* use the name returned and the buffer you safed off in pre-CREATE to
construct the name.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 1:51 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Hi Molly,

thank you very much for your explanation. However, I’m curious about few
things.

> After the CREATE has been sent to the file system, it is no longer
> safe to build the name from the FileObject->RelatedFileObject and

Is this because the file might be redirected to another file/volume by a
reparse point? The reason I’m asking this is because I use reparse
points only as a “marking” for files - if a file has the correct reparse
point tag, the path name is resolved and sent to a user-mode application
where the file is restored. I’m wondering if it is OK to assume that
FileObject->RelatedFileObject and FileObject->FileName are valid in this
situation (the reparse point does not redirect the file to another file
object/volume).

> If you need the name for this file object, try querying the opened
> name in pre-CREATE, then passing that to your post-CREATE callback.
> Querying

I think this creates significant overhead to the minifilter. I was
hoping to do filename resolving only for files with my reparse point
tags.

Your help is appreciated.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 22:07, Molly Brown wrote:
> Yes, it is because of the reparse point that you are getting this

error.

> After the CREATE has been sent to the file system, it is no longer
> safe to build the name from the FileObject->RelatedFileObject and
> FileObject->FileName fields, so Filter Manager must query the file
> system for the name. If STATUS_REPARSE is returned, the file object
> returned from this CREATE was not successfully initialized by the file
>
> system, therefore, Filter Manager cannot query the file system for the
>
> name.
>
> If you monitor the volume that will succeed the CREATE, you should be
> able to get the name in post-CREATE then.
>
> If you need the name for this file object, try querying the opened
> name in pre-CREATE, then passing that to your post-CREATE callback.
> Querying a normalized name will not work because during the
> normalization process, Filter Manager will detect that the name is
> going to go to a different volume and fail the

FltGetFileNameInformation() call.

> Regards,
> Molly Brown
> Microsoft Corporation
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> Sent: Tuesday, March 22, 2005 3:02 AM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
> RC
>
> Hi Molly,
>
> the device is the local C: drive while the filename is c:\tmp\bla.txt.
>
> Process Accessing File: cmd.exe
> Device Object: \Device\HarddiskVolume1
> pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
> pRelatedObject->FileObject->FileName = “\tmp\bla.txt”
>
> I tried using all 4 query methods with the same result (default, cache
>
> only, filesystem only and always allow cache lookup).
>
> After investigating this issue further, I found out that the error is
> not returned for every file, but for files with Reparse Points. The
> reason
> FltGetFileNameInformation() fails every time is that I call this
> function only for files with specific reparse point tags. This is also
>
> the reason I’m calling FltGetFileNameInformation() in the POST-create.
> Could reparse points be the problem?
>
> Thank you for your help on this issue,
>
> Regards,
> Mitja Horvat
>
> On Tuesday 22 of March 2005 02:24, Molly Brown wrote:
> > Mitja,
> >
> > What is the name in the TargetFileObject->FileName? Is the device a
> >
> > local or remote file system? Also, what query method are you using?
> >
> > Regards,
> > Molly Brown
> > Microsoft Corporation
> >
> > This posting is provided “AS IS” with no warranties and confers no
> > rights.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> > Sent: Monday, March 21, 2005 9:14 AM
> > To: Windows File Systems Devs Interest List
> > Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
> >
> > RC
> >
> > Hi again,
> >
> > there are few details I would like to add:
> >
> > - I tried using FltGetFileNameInformation() with the
> > FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both
> > cases it returns STATUS_FLT_INVALID_NAME_REQUEST.
> >
> > - I can successfully resolve the filename if I querythe device
>
> name
>
> > with
> > ObNameString() and append the
> > pData->Iopb->TargetFileObject->FileName
> > string
> >
> > Regards,
> > Mitja Horvat
> >
> > On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> > > Hi all,
> > >
> > > I’m having problems with FltGetFileNameInformation() function on
> > > Windows
> > > 2003 SP1 RC.
> > >
> > > The problem is that the function in question always returns
> > > STATUS_FLT_INVALID_NAME_REQUEST.
> > >
> > > According to the documentation, FltGetFileNameInformation()
> > > returns this error if:
> > > 1) TopLevelIrp of the current thread is not NULL
> > > 2) in case of PAGING I/O
> > > 3) if in post-close
> > > 4) if in pre-create
> > >
> > > My minifilter driver hooks to the post-create callback
> > > (IRP_MJ_CREATE postop), therefore cases 3) and 4) are not the
> > > culprits. As for 1 and 2, I added few DbgPrints() to the filter,
>
> and:
> > > 1) IoGetTopLevelIpr() is NULL
> > > 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
> > >
> > > I would like to know if there are other causes for the
> > > STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known
>
> bug?
>
> > > The minifilter (and FltGetFileNameInformation()) works as expected
> > >
> > > on Windows XP SP2.
> > >
> > > Thanks in advance for any help regarding this issue.
> > >
> > > Best Regards,
> > > Mitja Horvat
> > >
> > > —
> > > Questions? First check the IFS FAQ at
> > > https://www.osronline.com/article.cfm?id=17
> > >
> > > You are currently subscribed to ntfsd as: xxxxx@hermes.si
> > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as:
> > xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: unknown lmsubst tag
>
> argument: ‘’
>
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag

argument: ‘’

> To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mitja,

We have recently modified filter manager to support the exact scenario
you are talking about. We defined a new flag to
FltGetFileNameInformation to support name retrieval when STATUS_REPARSE
is returned. Here is the definition of the flag along with the comment
about it:

//
// This flag denotes that it is safe to query the name in post-CREATE
if
// STATUS_REPARSE was returned. To ensure the name returned is valid,
// the call must know that the FileObject->FileName was not changed
before
// STATUS_REPARSE was returned.
//
#define FLT_FILE_NAME_ALLOW_QUERY_ON_REPARSE 0x04000000

I checked when this was added and it should be present in Srv03 SP1 RC1.

Please try this out and see if it solves your problem.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 2:31 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Molly, thank you very much for your answer.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 23:24, Molly Brown wrote:

You cannot be guaranteed that the file system did not change the
FileObject->FileName while processing the CREATE, therefore it could
not
longer have the same data in it.

The FileObject->RelatedFileObject would still be referenced in
post-CREATE, so you could do the following:
* in pre-CREATE, make a copy of FileObject->FileName and pass that to
post-CREATE
* in post-CREATE, if you see your reparse tag, use
FltGetFileNameInformation to get the name of the
FileObject->RelatedFileObject, else free your saved name buffer
* use the name returned and the buffer you safed off in pre-CREATE to
construct the name.

Regards,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 1:51 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
RC

Hi Molly,

thank you very much for your explanation. However, I’m curious about
few
things.

> After the CREATE has been sent to the file system, it is no longer
> safe to build the name from the FileObject->RelatedFileObject and

Is this because the file might be redirected to another file/volume by
a
reparse point? The reason I’m asking this is because I use reparse
points only as a “marking” for files - if a file has the correct
reparse
point tag, the path name is resolved and sent to a user-mode
application
where the file is restored. I’m wondering if it is OK to assume that
FileObject->RelatedFileObject and FileObject->FileName are valid in
this
situation (the reparse point does not redirect the file to another
file
object/volume).

> If you need the name for this file object, try querying the opened
> name in pre-CREATE, then passing that to your post-CREATE callback.
> Querying

I think this creates significant overhead to the minifilter. I was
hoping to do filename resolving only for files with my reparse point
tags.

Your help is appreciated.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 22:07, Molly Brown wrote:
> Yes, it is because of the reparse point that you are getting this

error.

> After the CREATE has been sent to the file system, it is no longer
> safe to build the name from the FileObject->RelatedFileObject and
> FileObject->FileName fields, so Filter Manager must query the file
> system for the name. If STATUS_REPARSE is returned, the file object
> returned from this CREATE was not successfully initialized by the
file
>
> system, therefore, Filter Manager cannot query the file system for
the
>
> name.
>
> If you monitor the volume that will succeed the CREATE, you should
be
> able to get the name in post-CREATE then.
>
> If you need the name for this file object, try querying the opened
> name in pre-CREATE, then passing that to your post-CREATE callback.
> Querying a normalized name will not work because during the
> normalization process, Filter Manager will detect that the name is
> going to go to a different volume and fail the

FltGetFileNameInformation() call.

> Regards,
> Molly Brown
> Microsoft Corporation
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> Sent: Tuesday, March 22, 2005 3:02 AM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
> RC
>
> Hi Molly,
>
> the device is the local C: drive while the filename is
c:\tmp\bla.txt.
>
> Process Accessing File: cmd.exe
> Device Object: \Device\HarddiskVolume1
> pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
> pRelatedObject->FileObject->FileName = “\tmp\bla.txt”
>
> I tried using all 4 query methods with the same result (default,
cache
>
> only, filesystem only and always allow cache lookup).
>
> After investigating this issue further, I found out that the error
is
> not returned for every file, but for files with Reparse Points. The
> reason
> FltGetFileNameInformation() fails every time is that I call this
> function only for files with specific reparse point tags. This is
also
>
> the reason I’m calling FltGetFileNameInformation() in the
POST-create.
> Could reparse points be the problem?
>
> Thank you for your help on this issue,
>
> Regards,
> Mitja Horvat
>
> On Tuesday 22 of March 2005 02:24, Molly Brown wrote:
> > Mitja,
> >
> > What is the name in the TargetFileObject->FileName? Is the device
a
> >
> > local or remote file system? Also, what query method are you
using?
> >
> > Regards,
> > Molly Brown
> > Microsoft Corporation
> >
> > This posting is provided “AS IS” with no warranties and confers no
> > rights.
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja
Horvat
> > Sent: Monday, March 21, 2005 9:14 AM
> > To: Windows File Systems Devs Interest List
> > Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003
SP1
> >
> > RC
> >
> > Hi again,
> >
> > there are few details I would like to add:
> >
> > - I tried using FltGetFileNameInformation() with the
> > FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both
> > cases it returns STATUS_FLT_INVALID_NAME_REQUEST.
> >
> > - I can successfully resolve the filename if I querythe device
>
> name
>
> > with
> > ObNameString() and append the
> > pData->Iopb->TargetFileObject->FileName
> > string
> >
> > Regards,
> > Mitja Horvat
> >
> > On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> > > Hi all,
> > >
> > > I’m having problems with FltGetFileNameInformation() function on
> > > Windows
> > > 2003 SP1 RC.
> > >
> > > The problem is that the function in question always returns
> > > STATUS_FLT_INVALID_NAME_REQUEST.
> > >
> > > According to the documentation, FltGetFileNameInformation()
> > > returns this error if:
> > > 1) TopLevelIrp of the current thread is not NULL
> > > 2) in case of PAGING I/O
> > > 3) if in post-close
> > > 4) if in pre-create
> > >
> > > My minifilter driver hooks to the post-create callback
> > > (IRP_MJ_CREATE postop), therefore cases 3) and 4) are not the
> > > culprits. As for 1 and 2, I added few DbgPrints() to the filter,
>
> and:
> > > 1) IoGetTopLevelIpr() is NULL
> > > 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
> > >
> > > I would like to know if there are other causes for the
> > > STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known
>
> bug?
>
> > > The minifilter (and FltGetFileNameInformation()) works as
expected
> > >
> > > on Windows XP SP2.
> > >
> > > Thanks in advance for any help regarding this issue.
> > >
> > > Best Regards,
> > > Mitja Horvat
> > >
> > > —
> > > Questions? First check the IFS FAQ at
> > > https://www.osronline.com/article.cfm?id=17
> > >
> > > You are currently subscribed to ntfsd as: xxxxx@hermes.si
> > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as:
> > xxxxx@windows.microsoft.com To unsubscribe send a blank email
to
> > xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: unknown lmsubst tag
>
> argument: ‘’
>
> > To unsubscribe send a blank email to
xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag

argument: ‘’

> To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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

Neal,

thank you very much, it works!! In the meantime I found out that if I set
IoStatus.Status to STATUS_SUCCESS before I call FltGetFileNameInfo() works,
but obvously the FLT_FILE_NAME_ALLOW_QUERY_ON_REPARSE is the way to do it.

Regards,
Mitja Horvat

On Thursday 24 of March 2005 10:38, Neal Christiansen wrote:

Mitja,

We have recently modified filter manager to support the exact scenario
you are talking about. We defined a new flag to
FltGetFileNameInformation to support name retrieval when STATUS_REPARSE
is returned. Here is the definition of the flag along with the comment
about it:

//
// This flag denotes that it is safe to query the name in post-CREATE
if
// STATUS_REPARSE was returned. To ensure the name returned is valid,
// the call must know that the FileObject->FileName was not changed
before
// STATUS_REPARSE was returned.
//
#define FLT_FILE_NAME_ALLOW_QUERY_ON_REPARSE 0x04000000

I checked when this was added and it should be present in Srv03 SP1 RC1.

Please try this out and see if it solves your problem.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
Sent: Tuesday, March 22, 2005 2:31 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1 RC

Molly, thank you very much for your answer.

Regards,
Mitja Horvat

On Tuesday 22 of March 2005 23:24, Molly Brown wrote:
> You cannot be guaranteed that the file system did not change the
> FileObject->FileName while processing the CREATE, therefore it could

not

> longer have the same data in it.
>
> The FileObject->RelatedFileObject would still be referenced in
> post-CREATE, so you could do the following:
> * in pre-CREATE, make a copy of FileObject->FileName and pass that to
> post-CREATE
> * in post-CREATE, if you see your reparse tag, use
> FltGetFileNameInformation to get the name of the
> FileObject->RelatedFileObject, else free your saved name buffer
> * use the name returned and the buffer you safed off in pre-CREATE to
> construct the name.
>
> Regards,
> Molly Brown
> Microsoft Corporation
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> Sent: Tuesday, March 22, 2005 1:51 PM
> To: Windows File Systems Devs Interest List
> Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1

RC

> Hi Molly,
>
> thank you very much for your explanation. However, I’m curious about

few

> things.
>
> > After the CREATE has been sent to the file system, it is no longer
> > safe to build the name from the FileObject->RelatedFileObject and
>
> Is this because the file might be redirected to another file/volume by

a

> reparse point? The reason I’m asking this is because I use reparse
> points only as a “marking” for files - if a file has the correct

reparse

> point tag, the path name is resolved and sent to a user-mode

application

> where the file is restored. I’m wondering if it is OK to assume that
> FileObject->RelatedFileObject and FileObject->FileName are valid in

this

> situation (the reparse point does not redirect the file to another

file

> object/volume).
>
> > If you need the name for this file object, try querying the opened
> > name in pre-CREATE, then passing that to your post-CREATE callback.
> > Querying
>
> I think this creates significant overhead to the minifilter. I was
> hoping to do filename resolving only for files with my reparse point
> tags.
>
> Your help is appreciated.
>
> Regards,
> Mitja Horvat
>
> On Tuesday 22 of March 2005 22:07, Molly Brown wrote:
> > Yes, it is because of the reparse point that you are getting this
>
> error.
>
> > After the CREATE has been sent to the file system, it is no longer
> > safe to build the name from the FileObject->RelatedFileObject and
> > FileObject->FileName fields, so Filter Manager must query the file
> > system for the name. If STATUS_REPARSE is returned, the file object
> > returned from this CREATE was not successfully initialized by the

file

> > system, therefore, Filter Manager cannot query the file system for

the

> > name.
> >
> > If you monitor the volume that will succeed the CREATE, you should

be

> > able to get the name in post-CREATE then.
> >
> > If you need the name for this file object, try querying the opened
> > name in pre-CREATE, then passing that to your post-CREATE callback.
> > Querying a normalized name will not work because during the
> > normalization process, Filter Manager will detect that the name is
> > going to go to a different volume and fail the
>
> FltGetFileNameInformation() call.
>
> > Regards,
> > Molly Brown
> > Microsoft Corporation
> >
> > This posting is provided “AS IS” with no warranties and confers no
> > rights.
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja Horvat
> > Sent: Tuesday, March 22, 2005 3:02 AM
> > To: Windows File Systems Devs Interest List
> > Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003 SP1
> > RC
> >
> > Hi Molly,
> >
> > the device is the local C: drive while the filename is

c:\tmp\bla.txt.

> > Process Accessing File: cmd.exe
> > Device Object: \Device\HarddiskVolume1
> > pData->Iopb->TargetFileObject->FileName = “\tmp\bla.txt”
> > pRelatedObject->FileObject->FileName = “\tmp\bla.txt”
> >
> > I tried using all 4 query methods with the same result (default,

cache

> > only, filesystem only and always allow cache lookup).
> >
> > After investigating this issue further, I found out that the error

is

> > not returned for every file, but for files with Reparse Points. The
> > reason
> > FltGetFileNameInformation() fails every time is that I call this
> > function only for files with specific reparse point tags. This is

also

> > the reason I’m calling FltGetFileNameInformation() in the

POST-create.

> > Could reparse points be the problem?
> >
> > Thank you for your help on this issue,
> >
> > Regards,
> > Mitja Horvat
> >
> > On Tuesday 22 of March 2005 02:24, Molly Brown wrote:
> > > Mitja,
> > >
> > > What is the name in the TargetFileObject->FileName? Is the device

a

> > > local or remote file system? Also, what query method are you

using?

> > > Regards,
> > > Molly Brown
> > > Microsoft Corporation
> > >
> > > This posting is provided “AS IS” with no warranties and confers no
> > > rights.
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Mitja

Horvat

> > > Sent: Monday, March 21, 2005 9:14 AM
> > > To: Windows File Systems Devs Interest List
> > > Subject: Re: [ntfsd] FltGetFileNameInformation() on Windows 2003

SP1

> > > RC
> > >
> > > Hi again,
> > >
> > > there are few details I would like to add:
> > >
> > > - I tried using FltGetFileNameInformation() with the
> > > FLT_FILE_NAME_NORMALIZED and FLT_FILE_NAME_OPENED flags. I both
> > > cases it returns STATUS_FLT_INVALID_NAME_REQUEST.
> > >
> > > - I can successfully resolve the filename if I querythe device
> >
> > name
> >
> > > with
> > > ObNameString() and append the
> > > pData->Iopb->TargetFileObject->FileName
> > > string
> > >
> > > Regards,
> > > Mitja Horvat
> > >
> > > On Monday 21 of March 2005 17:58, Mitja Horvat wrote:
> > > > Hi all,
> > > >
> > > > I’m having problems with FltGetFileNameInformation() function on
> > > > Windows
> > > > 2003 SP1 RC.
> > > >
> > > > The problem is that the function in question always returns
> > > > STATUS_FLT_INVALID_NAME_REQUEST.
> > > >
> > > > According to the documentation, FltGetFileNameInformation()
> > > > returns this error if:
> > > > 1) TopLevelIrp of the current thread is not NULL
> > > > 2) in case of PAGING I/O
> > > > 3) if in post-close
> > > > 4) if in pre-create
> > > >
> > > > My minifilter driver hooks to the post-create callback
> > > > (IRP_MJ_CREATE postop), therefore cases 3) and 4) are not the
> > > > culprits. As for 1 and 2, I added few DbgPrints() to the filter,
> >
> > and:
> > > > 1) IoGetTopLevelIpr() is NULL
> > > > 2) (pData->Iopb->IrpFlags & IRP_PAGING_IO) is FALSE
> > > >
> > > > I would like to know if there are other causes for the
> > > > STATUS_FLT_INVALID_NAME_REQUEST error code or if this is a known
> >
> > bug?
> >
> > > > The minifilter (and FltGetFileNameInformation()) works as

expected

> > > > on Windows XP SP2.
> > > >
> > > > Thanks in advance for any help regarding this issue.
> > > >
> > > > Best Regards,
> > > > Mitja Horvat
> > > >
> > > > —
> > > > Questions? First check the IFS FAQ at
> > > > https://www.osronline.com/article.cfm?id=17
> > > >
> > > > You are currently subscribed to ntfsd as: xxxxx@hermes.si
> > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the IFS FAQ at
> > > https://www.osronline.com/article.cfm?id=17
> > >
> > > You are currently subscribed to ntfsd as:
> > > xxxxx@windows.microsoft.com To unsubscribe send a blank email

to

> > > xxxxx@lists.osr.com
> > >
> > > —
> > > Questions? First check the IFS FAQ at
> > > https://www.osronline.com/article.cfm?id=17
> > >
> > > You are currently subscribed to ntfsd as: unknown lmsubst tag
> >
> > argument: ‘’
> >
> > > To unsubscribe send a blank email to

xxxxx@lists.osr.com

> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as:
> > xxxxx@windows.microsoft.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> > —
> > Questions? First check the IFS FAQ at
> > https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: unknown lmsubst tag
>
> argument: ‘’
>
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:

xxxxx@windows.microsoft.com

> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag

argument: ‘’

> To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com