The goal of the filter managers naming APIs are to simplify name
retrieval for filters and to make it as efficient as possible. They
return the correct name based on a given file object.
The naming APIs support 3 kinds of names.
Opened name - This is a full path name the way the file was opened.
Mount points are resolved and related file objects are expanded. Note
that this name may contain both long and short names. This is fairly
quick and easy to generate.
Normalized name - This retrieves the opened name and then parses through
all of the components looking for potential short names. Any time it
finds a potential short name it opens that directory, queries for the
long name and does the appropriate substitution for that component.
Short name - This simply returns the short name for the given file.
There is no path component.
Names are returned via a name information structure. These structures
are reference counted and must be released by a filter when they are
done with them. Once created, a given structure is never change, thus
no synchronization is needed to access them.
There is a naming API to parse the name in a name information structure
into its component parts (ex: path, name, extension, stream). This is
done without copying the name; it uses UNICODE_STRINGS and simply sets
up appropriate pointers and lengths to the various components.
The naming APIs correctly deal with renames. The name returned is
accurate at the time it was generated. We do not synchronize across
renames, if you need that, it is your responsibility. A rename never
changes an existing name information structure. A new structure will be
generated the next time the name is queried.
The naming APIs correctly deal with hard links. The name returned will
be based on which path the given file object was opened with. We don’t
have any support for correlating different names to the same file.
The naming APIs correctly deal with open by ID. We have not seen any
permission issues with this. If someone has explicit scenarios where
they have seen this not work, I would be interested in it.
The naming APIs correctly deal with share names from redirectors. It
supports the different share naming syntaxes across the different OS
versions.
Because of the work involved in generating name, the filter manager
caches names. We do this to amortize the cost of generating names
across multiple filters that need them. The cache does properly handle
renames as well as hard links.
The naming APIs support querying for a file name during pre-create and
it properly handles the normalization.
The naming APIs know when it is safe to retrieve a name and when it is
not. Therefore they eliminate the deadlocks people see from doing name
queries when they shouldn’t. There is an option to retrieve a name if
it is in the cache even if it would be unsafe to retrieve it otherwise.
There is a naming API to retrieve the destination name of a rename or
hard link operation. This can return both the “opened” or “normalized”
version of the name.
There is a naming API to determine if a given name has been Tunneled or
not.
I hope this helps answer your question and I hope it gets you excited
for using the filter manager in the future. All of this information is
documented in the IFSKit.
If anyone has ideas for common functionality that would benefit multiple
filters we are open to suggestions for future enhancements.
Neal Christiansen
Microsoft File System Filter Group
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 Dejan Maksimovic
Sent: Wednesday, December 10, 2003 3:08 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: Strange problem
I wonder how the new Filter Driver Framework takes care of such
things? Anyone
from MS care to comment?
Nick Ryan wrote:
Good point. Plus files opened by ID for which one doesn’t have the
permissions to query the directories in the path above.Lyndon J. Clarke wrote:
> What canonical LFN? Hard links …
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa File Monitor - File monitoring library for Win32 developers.
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