Releasing PFLT_FILE_NAME_INFORMATION

After calling FltGetFileNameInformation and getting a
PFLT_FILE_NAME_INFORMATION how long can the structure be held before calling
FltReleaseFileNameInformation and/or what are the impact for holding it for
the following periods.

Can it be held from the Pre Operation thru the Post Operation?

Can it be held the entire time the file is opened CREATE -> CLOSE?

Thanks,

Ken

There are two issues to consider about holding the
FLT_FILE_NAME_INFORMATION for extended periods of time:

  1. The name in this structure is *not* updated when the stream is
    renamed or otherwise invalidated, therefore you may be dealing with a
    stale name (which may or may not matter to you).

  2. As long as you have a reference on the structure, the memory
    associated with the name cannot be freed even if the name is invalided
    by a rename or create hardlink operation.

Even if the name is in the cache kept by the FIlter Manager, the amount
of work that FltGetFileNameInformation must do to get you a name is
non-negligible – we don’t have to do file system operations, but we do
need to acquire one or more locks. Therefore, it’s completely
reasonable to hold the FLT_FILE_NAME_INFORMATION structure from
pre-operation through post-operation.

Depending on your use of the name, you should only hold the
FLT_FILE_NAME_INFORMATION structure from CREATE through CLOSE if you
also have logic to recognize operations that would invalidate this name
and do the correct thing with respect to your filter. Typically, that
would be releasing your current FLT_FILE_NAME_INFORMATION structure and
re-querying the name if you still need it.

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, February 26, 2004 2:32 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

After calling FltGetFileNameInformation and getting a
PFLT_FILE_NAME_INFORMATION how long can the structure be held before
calling FltReleaseFileNameInformation and/or what are the impact for
holding it for the following periods.

Can it be held from the Pre Operation thru the Post Operation?

Can it be held the entire time the file is opened CREATE -> CLOSE?

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

How does one “recognize operations that would invalidate this name”?
I can understand a name changing after a rename, but how does a name change
otherwise?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, February 26, 2004 6:37 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

There are two issues to consider about holding the
FLT_FILE_NAME_INFORMATION for extended periods of time:

  1. The name in this structure is *not* updated when the stream is
    renamed or otherwise invalidated, therefore you may be dealing with a
    stale name (which may or may not matter to you).

  2. As long as you have a reference on the structure, the memory
    associated with the name cannot be freed even if the name is invalided
    by a rename or create hardlink operation.

Even if the name is in the cache kept by the FIlter Manager, the amount
of work that FltGetFileNameInformation must do to get you a name is
non-negligible – we don’t have to do file system operations, but we do
need to acquire one or more locks. Therefore, it’s completely
reasonable to hold the FLT_FILE_NAME_INFORMATION structure from
pre-operation through post-operation.

Depending on your use of the name, you should only hold the
FLT_FILE_NAME_INFORMATION structure from CREATE through CLOSE if you
also have logic to recognize operations that would invalidate this name
and do the correct thing with respect to your filter. Typically, that
would be releasing your current FLT_FILE_NAME_INFORMATION structure and
re-querying the name if you still need it.

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, February 26, 2004 2:32 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

After calling FltGetFileNameInformation and getting a
PFLT_FILE_NAME_INFORMATION how long can the structure be held before
calling FltReleaseFileNameInformation and/or what are the impact for
holding it for the following periods.

Can it be held from the Pre Operation thru the Post Operation?

Can it be held the entire time the file is opened CREATE -> CLOSE?

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

Stream renames are the main operations to be concerned about.

If all the handles are closed, the parent directory could be renamed and
that would invalidate your name if you hold onto it past CLEANUP.

If you are storing the name in your stream context, hardlink creation
affects you. While associating the stream and the name is valid as long
as there is a link count of 1 on the stream, when there is more than one
name that can reference the stream, you can no longer make this
association since a given file object may have opened using more than
one name.

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: Friday, February 27, 2004 9:11 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

How does one “recognize operations that would invalidate this name”?
I can understand a name changing after a rename, but how does a name
change otherwise?

Ken

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, February 26, 2004 6:37 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

There are two issues to consider about holding the
FLT_FILE_NAME_INFORMATION for extended periods of time:

  1. The name in this structure is *not* updated when the stream is
    renamed or otherwise invalidated, therefore you may be dealing with a
    stale name (which may or may not matter to you).

  2. As long as you have a reference on the structure, the memory
    associated with the name cannot be freed even if the name is invalided
    by a rename or create hardlink operation.

Even if the name is in the cache kept by the FIlter Manager, the amount
of work that FltGetFileNameInformation must do to get you a name is
non-negligible – we don’t have to do file system operations, but we do
need to acquire one or more locks. Therefore, it’s completely
reasonable to hold the FLT_FILE_NAME_INFORMATION structure from
pre-operation through post-operation.

Depending on your use of the name, you should only hold the
FLT_FILE_NAME_INFORMATION structure from CREATE through CLOSE if you
also have logic to recognize operations that would invalidate this name
and do the correct thing with respect to your filter. Typically, that
would be releasing your current FLT_FILE_NAME_INFORMATION structure and
re-querying the name if you still need it.

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, February 26, 2004 2:32 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

After calling FltGetFileNameInformation and getting a
PFLT_FILE_NAME_INFORMATION how long can the structure be held before
calling FltReleaseFileNameInformation and/or what are the impact for
holding it for the following periods.

Can it be held from the Pre Operation thru the Post Operation?

Can it be held the entire time the file is opened CREATE -> CLOSE?

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

Where can I find doccumentation on this call? It is not used in fastfat, google turns up nothing, the IFS docs have nothing on it, it’s not mentioned in any of the files in \winddk\3790\inc (win2k3 ifskit), and this is the only discussion on this newsgroup that talks about it.

Thanks,
Jeremy
“Ken Galipeau” wrote in message news:xxxxx@ntfsd…
After calling FltGetFileNameInformation and getting a PFLT_FILE_NAME_INFORMATION how long can the structure be held before calling FltReleaseFileNameInformation and/or what are the impact for holding it for the following periods.

Can it be held from the Pre Operation thru the Post Operation?

Can it be held the entire time the file is opened CREATE -> CLOSE?

Thanks,

Ken

Jeremy,

This is an API of the new Filter Manager architecture. As has been recently announced to this list, the filter manager is now part of XP SP2 and Server 2003 SP1.

A beta version of the IFSKit that supports the filter manager, and contains extensive documentation, is available to anyone that has already purchased an IFSKit for Windows 2000 or later.

You can go to Microsoft’s BetaPlace web site (http://beta.microsoft.com) and signup for the beta. For “Guest ID” specify “Filtermgr”

Below is a copy of the email I sent to this list in December describing the Filter Manager.

Neal Christiansen

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

I want to update the file system filter developer community with the latest information that was announced at the November 2003 IFS PlugFest. The PlugFest was part of the DDC (Driver Developers Conference) that was held November 11-14 on the Microsoft campus.

At this time we announced the platforms the new file system filter manager will be released on. These include:

  • XP SP2
  • Server 2003 SP1
  • Windows 2000 (release mechanisms to be determined)
  • Longhorn

Full support for developing mini-filters will be released in the Server 2003 IFSKit. This kit will support mini-filter development for both XP SP2 and Server 2003 SP1. A beta version of this kit will be available for the XP SP2 time frame. An alpha version of this kit was given out at the last PlugFest.

Now is the time to start making plans to port your existing filters to be mini-filters. Some reason for doing this are:

  • The elimination of reboots. The filter manager supports mini-filters being loaded and unloaded at any time.

  • Deterministic load ordering. The filter manager supports a new “altitude” model for controlling the order mini-filters are attached. A mini-filter will be attached at its proper altitude regardless of when it is loaded.

  • Reduction of kernel stack overflows. The filter manager uses a new callback model instead of the existing call-through model. This greatly reduces the amount of kernel stack consumed by filters.

  • Full interoperability support between existing filters and mini-filters.

  • Elimination of substantial complexity from the typical filter driver by providing built in support for functionality common to most filters. Some of this support includes:

  • Retrieving file names

  • Normalizing file names (removal of short names)

  • Parsing file names

  • Name caching

  • Context support

  • IO library which supports targeting operations below your filter

There are many other reasons as well.

Please fell free to start asking Filter Manager related questions on this list.


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeremy Sherrill
Sent: Friday, February 27, 2004 10:39 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Releasing PFLT_FILE_NAME_INFORMATION

Where can I find doccumentation on this call?? It is not used in fastfat, google turns up nothing, the IFS docs have nothing on it, it’s not mentioned in any of the files in \winddk\3790\inc (win2k3 ifskit), and this is the only discussion on this newsgroup that talks about it.
?
Thanks,
Jeremy
“Ken Galipeau” wrote in message news:xxxxx@ntfsd…
After calling FltGetFileNameInformation and getting a PFLT_FILE_NAME_INFORMATION how long can the structure be held before calling FltReleaseFileNameInformation and/or what are the impact for holding it for the following periods.

Can it be held from the Pre Operation thru the Post Operation?
Can it be held the entire time the file is opened CREATE -> CLOSE?

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