FltGetFileNameInformation

NTFSD
1

I’m calling FltGetFileNameInformation during the Pre Operation callback and
at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet the
FileObject contains a string with a valid name. I understand that a path may
not actually exist but why not return the name from the FileObject since
that is the name begin opened? This tells me that if I can’t get the name
from FltGetFileNameInformation I then have to go back and use the method I
previously used. Sounds like more work using the filter mananger rather then
less.

Below is some debug output for a query that worked and then a query that
didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_6595b6
4144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Commo
n-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-US
_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-US_6
595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

2

What do you mean by a pre operation callback?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback and
at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet the
FileObject contains a string with a valid name. I understand that a path may
not actually exist but why not return the name from the FileObject since
that is the name begin opened? This tells me that if I can’t get the name
from FltGetFileNameInformation I then have to go back and use the method I
previously used. Sounds like more work using the filter mananger rather then
less.

Below is some debug output for a query that worked and then a query that
didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_6595b6
4144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Commo
n-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-US
_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-US_6
595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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

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

3

It’s where the Filter Manager calls the Mini Filter instance when a file is
opened, analogous to IRP CREATE call back function.

From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Friday, March 05, 2004 4:14 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

What do you mean by a pre operation callback?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback and
at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet the
FileObject contains a string with a valid name. I understand that a path may
not actually exist but why not return the name from the FileObject since
that is the name begin opened? This tells me that if I can’t get the name
from FltGetFileNameInformation I then have to go back and use the method I
previously used. Sounds like more work using the filter mananger rather then
less.

Below is some debug output for a query that worked and then a query that
didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_6595b6
4144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Commo
n-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-US
_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-US_6
595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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

You are currently subscribed to ntfsd as: xxxxx@storagecraft.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: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet
the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back
and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that
didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65
95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C
ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e
n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-
US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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

5

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The problem
is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet
the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back
and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that
didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65
95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C
ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e
n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-
US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in
the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS
name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.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: xxxxx@windows.microsoft.com

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

7

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the
    underlying open is going to fail and ignore the file open.

  2. If the get fails and I want the name I can request the OPENED name.

Is there any way to know that the opened name has short components so I can
then query for the normalized name?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in
the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS
name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.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: 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: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

If you are looking to normalize the name, there is an alternate method:

  • Check for related file object. If one exists, call the FSD to get
    its name; this will not fail

  • Append the name in the file object from the create call you are
    processing

This is a canonical name and does not require a pre-open to build the name.

Jamey

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the
    underlying open is going to fail and ignore the file open.

  2. If the get fails and I want the name I can request the OPENED name.

Is there any way to know that the opened name has short components so I can
then query for the normalized name?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in
the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS
name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.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: 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: xxxxx@legato.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: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Yes – in pre-create this is a valid assumption. The one exception is
STATUS_INSUFFICIENT_RESOURCES since that means we couldn’t allocate the
memory for name to return, but potentially, the allocations requested by
the file system to handle the CREATE may be luckier and succeed. You
should treat this in the same way you would if you got
STATUS_INSUFFICIENT_RESOURCES while setting up your filter’s state for
this create.

There is not an easy way to determine if a name has short components.
You have to inspect each component to make sure it is not a valid DOS
name (RtlIsNameLegalDOS8Dot3). If it is not a legal DOS 8.3 name, you
know you’ve got a long name here so no more work needs to be done.
Unfortunately, most names fit the format where they could be legal DOS
8.3 names, but you don’t know for sure until you query the file system.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the
    underlying open is going to fail and ignore the file open.

  2. If the get fails and I want the name I can request the OPENED name.

Is there any way to know that the opened name has short components so I
can then query for the normalized name?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in

the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS

name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this

error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.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: 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: xxxxx@legato.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: xxxxx@windows.microsoft.com

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

10

I use this method in my legacy filter, my questions pertain to the Mini
Filter model.

Thanks,

Ken

From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Friday, March 05, 2004 2:24 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you are looking to normalize the name, there is an alternate method:

  • Check for related file object. If one exists, call the FSD to get
    its name; this will not fail

  • Append the name in the file object from the create call you are
    processing

This is a canonical name and does not require a pre-open to build the name.

Jamey

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the
    underlying open is going to fail and ignore the file open.

  2. If the get fails and I want the name I can request the OPENED name.

Is there any way to know that the opened name has short components so I can
then query for the normalized name?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com
mailto:xxxxx ]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in
the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS
name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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



From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com
mailto:xxxxx] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com
mailto:xxxxx]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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



From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com
mailto:xxxxx] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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

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
https:

You are currently subscribed to ntfsd as: xxxxx@legato.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
https:

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
https:

You are currently subscribed to ntfsd as: xxxxx@legato.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: xxxxx@storagecraft.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: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</https:></https:></https:></https:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

11

I know that a short name does not have to have a ~ in it, but for the most
part they all do if generated by the system. How about an option to only
normalize parts that have a tilde as per the standard short name generation
model.

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 2:46 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

Yes – in pre-create this is a valid assumption. The one exception is
STATUS_INSUFFICIENT_RESOURCES since that means we couldn’t allocate the
memory for name to return, but potentially, the allocations requested by
the file system to handle the CREATE may be luckier and succeed. You
should treat this in the same way you would if you got
STATUS_INSUFFICIENT_RESOURCES while setting up your filter’s state for
this create.

There is not an easy way to determine if a name has short components.
You have to inspect each component to make sure it is not a valid DOS
name (RtlIsNameLegalDOS8Dot3). If it is not a legal DOS 8.3 name, you
know you’ve got a long name here so no more work needs to be done.
Unfortunately, most names fit the format where they could be legal DOS
8.3 names, but you don’t know for sure until you query the file system.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the
    underlying open is going to fail and ignore the file open.

  2. If the get fails and I want the name I can request the OPENED name.

Is there any way to know that the opened name has short components so I
can then query for the normalized name?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in

the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS

name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this

error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.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: 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: xxxxx@legato.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: 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: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

12

We cannot do that since it would be potentially incorrect since, as you
said, not all short file names contain ‘~’. We do cache the names
generated, even in pre-CREATE operations, therefore we are amortizing
the cost of doing this work across all minifilters requesting names.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 12:27 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

I know that a short name does not have to have a ~ in it, but for the
most part they all do if generated by the system. How about an option to
only normalize parts that have a tilde as per the standard short name
generation model.

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 2:46 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

Yes – in pre-create this is a valid assumption. The one exception is
STATUS_INSUFFICIENT_RESOURCES since that means we couldn’t allocate the
memory for name to return, but potentially, the allocations requested by

the file system to handle the CREATE may be luckier and succeed. You
should treat this in the same way you would if you got
STATUS_INSUFFICIENT_RESOURCES while setting up your filter’s state for
this create.

There is not an easy way to determine if a name has short components.
You have to inspect each component to make sure it is not a valid DOS
name (RtlIsNameLegalDOS8Dot3). If it is not a legal DOS 8.3 name, you
know you’ve got a long name here so no more work needs to be done.
Unfortunately, most names fit the format where they could be legal DOS
8.3 names, but you don’t know for sure until you query the file system.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the

underlying open is going to fail and ignore the file open.

  1. If the get fails and I want the name I can request the OPENED name.

Is there any way to know that the opened name has short components so I
can then query for the normalized name?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 12:50 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
operation is going to fail because the name is not valid. When you
request a NORMALIZED name, the Filter Manager needs to take the same
steps a legacy filter needs to do today to ensure that each component in

the path has been expanded to its long form. Therefore, Filter Manager
iterates through the components in the path, checks if it could be a DOS

name, and if so, opens the parent directory and queries for
FileNamesInformation. If the name provided isn’t valid, Filter Manager
will get an error in that processing and return it to the caller.

If you requested the OPENED name, Filter Manager wouldn’t try to do the
short name expansion, therefore, the FltGetFileNameInformation request
would succeed since, for a CREATE where the full path is specified,
Filter Manger is essentially just gluing together the device name with
the name in the FileObject->FileName buffer.

Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this

error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error. The
problem is if it ends up not failing I’ve missed detecting the “open”.

I was requesting NORMALIZED?

Thanks,
Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?

In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?

Thanks,
Molly Brown
Microsoft Corporation

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet

the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back

and use the method I previously used. Sounds like more work using the
filter mananger rather then less.

Below is some debug output for a query that worked and then a query that

didn’t work.

IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65

95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C

ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest

IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e

n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

PtPreOperationCreate: Entered

Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58

FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-

US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL

Thanks,

Ken

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: xxxxx@legato.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: 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: xxxxx@legato.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: 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: xxxxx@legato.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: xxxxx@windows.microsoft.com

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

13

Jamey,

In the filter manager model the preOperation callback is the “dispatch” routine and the postOperation callback is the “completion” routine. These are the names we use in the structure which registers which operations you are interested in. We choose them because their meaning was clearer

The filter manager provides name retrieval and normalization APIs. They do underneath exactly what you are describing.

As people move to the mini-filter model we want them to use the filter managers naming code. The reason for this is a lot of filters don’t do it quite right. We properly handle name generation and know when it is safe to query names. We also cache the names to help reduce the burden on the system of having multiple filters query the names.

Neal Christiansen

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

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Friday, March 05, 2004 11:24 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

If you are looking to normalize the name, there is an alternate method:

  • Check for related file object. If one exists, call the FSD to get its name; this will not fail
  • Append the name in the file object from the create call you are processing

This is a canonical name and does not require a pre-open to build the name.

Jamey

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the underlying open is going to fail and ignore the file open.
  2. If the get fails and I want the name I can request the OPENED name.
    Is there any way to know that the opened name has short components so I can then query for the normalized name?
    Ken
    -----Original Message-----
    From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
    Sent: Friday, March 05, 2004 12:50 PM
    To: Windows File Systems Devs Interest List
    Subject: RE: [ntfsd] FltGetFileNameInformation
    If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
    requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
    operation is going to fail because the name is not valid.? When you
    request a NORMALIZED name, the Filter Manager needs to take the same
    steps a legacy filter needs to do today to ensure that each component in
    the path has been expanded to its long form.? Therefore, Filter Manager
    iterates through the components in the path, checks if it could be a DOS
    name, and if so, opens the parent directory and queries for
    FileNamesInformation.? If the name provided isn’t valid, Filter Manager
    will get an error in that processing and return it to the caller.
    ?
    If you requested the OPENED name, Filter Manager wouldn’t try to do the
    short name expansion, therefore, the FltGetFileNameInformation request
    would succeed since, for a CREATE where the full path is specified,
    Filter Manger is essentially just gluing together the device name with
    the name in the FileObject->FileName buffer.
    ?
    Molly Brown
    Microsoft Corporation
    ?
    This posting is provided “AS IS” with no warranties and confers no
    rights.
    ?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error.? The
problem is if it ends up not failing I’ve missed detecting the “open”.
I was requesting NORMALIZED?
Thanks,
Ken
-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation
When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?
In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?
Thanks,
Molly Brown
Microsoft Corporation
?
This posting is provided “AS IS” with no warranties and confers no
rights.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet
the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back
and use the method I previously used. Sounds like more work using the
filter mananger rather then less.
Below is some debug output for a query that worked and then a query that
didn’t work.
IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65
95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest
PtPreOperationCreate: Entered
??? Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58
??? FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C
ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest
IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e
n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL
PtPreOperationCreate: Entered
??? Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58
??? FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-
US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL
Thanks,
Ken

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: xxxxx@legato.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: 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: xxxxx@legato.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: xxxxx@storagecraft.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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

14

Ken,

If you ever find that a name query for a normalized name from the filter manager fails but the open succeeds please let us know about this because it should never happen and we would want to figure out what happened. Of course as Molly said this would not apply if an out-of-memory error was returned.

Neal Christiansen

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

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 11:20 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

So, you saying:

  1. If I get a “not found” error when fetching the name, I can assume the underlying open is going to fail and ignore the file open.
  2. If the get fails and I want the name I can request the OPENED name.
    Is there any way to know that the opened name has short components so I can then query for the normalized name?
    Ken
    -----Original Message-----
    From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
    Sent: Friday, March 05, 2004 12:50 PM
    To: Windows File Systems Devs Interest List
    Subject: RE: [ntfsd] FltGetFileNameInformation
    If you get an error other than STATUS_INSUFFICIENT_RESOURCES when
    requesting a NORMALIZED name in pre-CREATE, it means that the CREATE
    operation is going to fail because the name is not valid.? When you
    request a NORMALIZED name, the Filter Manager needs to take the same
    steps a legacy filter needs to do today to ensure that each component in
    the path has been expanded to its long form.? Therefore, Filter Manager
    iterates through the components in the path, checks if it could be a DOS
    name, and if so, opens the parent directory and queries for
    FileNamesInformation.? If the name provided isn’t valid, Filter Manager
    will get an error in that processing and return it to the caller.
    ?
    If you requested the OPENED name, Filter Manager wouldn’t try to do the
    short name expansion, therefore, the FltGetFileNameInformation request
    would succeed since, for a CREATE where the full path is specified,
    Filter Manger is essentially just gluing together the device name with
    the name in the FileObject->FileName buffer.
    ?
    Molly Brown
    Microsoft Corporation
    ?
    This posting is provided “AS IS” with no warranties and confers no
    rights.
    ?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 9:35 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation

No, it did not succeed yet. It is in the Pre Op Callback when I get this
error. For curiousity sake I checked the CREATE result in the Post Op
Callback and the create also fails there with the same error.? The
problem is if it ends up not failing I’ve missed detecting the “open”.
I was requesting NORMALIZED?
Thanks,
Ken
-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, March 05, 2004 11:30 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltGetFileNameInformation
When you say that the FileObject contains a valid name, does that mean
the CREATE operation succeeded?
In your call to FltGetFileNameInformation, what name format did you
request OPENED or NORMALIZED?
Thanks,
Molly Brown
Microsoft Corporation
?
This posting is provided “AS IS” with no warranties and confers no
rights.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Thursday, March 04, 2004 5:42 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] FltGetFileNameInformation

I’m calling FltGetFileNameInformation during the Pre Operation callback
and at times I get an error C000003A (STATUS_OBJECT_PATH_NOT_FOUND). Yet
the FileObject contains a string with a valid name. I understand that a
path may not actually exist but why not return the name from the
FileObject since that is the name begin opened? This tells me that if I
can’t get the name from FltGetFileNameInformation I then have to go back
and use the method I previously used. Sounds like more work using the
filter mananger rather then less.
Below is some debug output for a query that worked and then a query that
didn’t work.
IrpCreat Irp 83152E00 FO F948FC58
C:\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.Common-Controls.mui_65
95b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest
PtPreOperationCreate: Entered
??? Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58
??? FltName FO=F948FC58
\Device\HarddiskVolume1\WINDOWS\WinSxS\Manifests\x86_Microsoft.Windows.C
ommon-Controls.mui_6595b64144ccf1df_6.0.10.0_en-US_e0908a4e.Manifest
IrpCreat Irp 82500E00 FO F948FC58
C:\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_e
n-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL
PtPreOperationCreate: Entered
??? Filter=817BB740, Volume=817694C0 Instance=813A5B10,
FileObject=F948FC58
??? FltGetFileNameInformation=c000003a F948FC58
\WINDOWS\assembly\GAC\Microsoft.Windows.Common-Controls.mui\6.0.10.0_en-
US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.mui.DLL
Thanks,
Ken

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: xxxxx@legato.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: 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: xxxxx@legato.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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com