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:
-
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).
-
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