FltParseFileNameInformation fails on contrived paths

NTFSD
1

When I call FltParseFileNameInformation() on a name returned by
FltGetFileNameInformation() it parses pretty well.

(Although sometimes it claims to have extracted
FLTFL_FILE_NAME_PARSED_PARENT_DIR but &name->ParentDir turns out to be
bogus).

However when I call it to parse a path I have constructed myself, using
my own FLT_FILE_NAME_INFORMATION, it fails to parse anything except the
FinalComponent.

Is this to be expected?

And why am I faking my own FLT_FILE_NAME_INFORMATION struct? I need to
parse the rename destination filename before I call
FltGetDestinationFileNameInformation so that I can extract the drive letter.

Normally the driver letter would be returned by
FltGetDestinationFileNameInformation in the form
\Driver\Mup;LanmanRedirector;p:=000000234\server\share
EXCEPT if I am also issuing STATUS_REPARSE during IRP_MJ_CREATE which
will then eats the drive letter and FltGetDestinationFileNameInformation
returns the re-parsed path without the drive letter.

I’ve also tried other contrived filenames which begin with \Device\Mup,
but FltParseFileNameInformation() remains steadfastly unilluminating.

Sam

2

Did you try FltParseFileName ?

(For some there is no link from the documentation page for FltParseFileNameInformation to the page for FltParseFileName, I’ve already filed a bug on that).

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

3

* Alexandru Carp wrote, On 03/11/09 16:47:

Did you try FltParseFileName ?

(For some there is no link from the documentation page for FltParseFileNameInformation to the page for FltParseFileName, I’ve already filed a bug on that).

I’d never noticed that one - thanks.

Sadly it can’t parse out the volume and share information which I was after.

I’ll knock my own up; are these rules OK?

For filenames beginning with a :

First use FltParseFileName to find where the FinalComponent starts (we
don’t need to worry about : in the filenames before then).

On the path before the final component:

To get the volume
up to the next \ is some kind of handler name;
e.g. ?? or Device
up to the next \ is the handlers volume name;
e.g. Mup or P: or UNC
while the next character is a ;
read up to the next \ and save as a volume instance attribute
(or server info attribute?)
If an attribute as the for *:… (where * is a single character);
e.g.
;p:=0000…
then the single character is the mapped driver letter.

To get the share
If the volume is ??*:\ (where * is a single character) then the
single character is the driver letter and there is no share available
unless the volume is normalized after suffixing a .
e.g.
??\P:.
using one of the FltGet*FileNameInformation* calls.
Otherwise the volume information can be had:
up to the next \ to get the server
up to the next \ to get the share

everything after that is the filename and can be parsed with
FltParseFileName.

And in my case the parsed path may not actually exist; I’m parsing to
work out if I need to re-write it to one that does exist - hence the
special treatment for ??\p:\ because I can’t call
FltGet*FileNameInformation* on the whole path as it is likely to fail,
so I find the shortest path to call that on, expecting the root
directory will at least exist!

Sam

4

Sorry Sam, but this is pretty much the reason we came up with FltParseFileName and FltParseFileNameInformation (to not have a “good way” of parsing file names filled with secret handshakes that only some people know about). So as you can imagine I’m more interested in making FltParseFileName and FltParseFileNameInformation work out of the box that in finding workarounds. With this in mind, please note that we have fixed a couple of bugs in those routines for Win7 so my advice would be to see if name parsing looks right in Win7 and if it does then we can work on requesting backports for those. If not we can discuss more about workarounds…

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

5

* Alexandru Carp wrote, On 04/11/09 17:09:

Sorry Sam, but this is pretty much the reason we came up with FltParseFileName and FltParseFileNameInformation (to not have a “good way” of parsing file names filled with secret handshakes that only some people know about). So as you can imagine I’m more interested in making FltParseFileName and FltParseFileNameInformation work out of the box that in finding workarounds. With this in mind, please note that we have fixed a couple of bugs in those routines for Win7 so my advice would be to see if name parsing looks right in Win7 and if it does then we can work on requesting backports for those. If not we can discuss more about workarounds…

That’s fine; I’ll try and conjure up a windows 7 box to try on.

I find the FltParseFileName API woefully deficient it doesn’t separate
the file system part from the volume or share.

I’ve not come across any documentation on MSDN to suggest that the
windows 7 functionality is any better,

Neither FltParseFileName or FltParseFileNameInformation is able to parse
the drive letter out in it’s various secret-handshaking forms (and maybe
I shouldn’t be looking, but the information seems to be persistently
available albeit in an inconsistent form).

Out of necessity for the time being, I’ve done my own parser based on
FltParseFileName that will parse a filename into 14 fields:

\SCHEMA\HANDLER;ATTRIBUTE;ATTRIBUTE\SERVERNAME\SHARENAME
schema handler|----attributes------| servername sharename
|–volume-----||--------------------share----------------|

\PARENT\DIR\FILENAME.EXT:STREAM
|parent-dir||-file-| ext stream
|-final-component-|
|------------path-------------|

and also the drive letter if found in ATTRIBUTE or HANDLER (for ??\p:)

adding to the normal fields: schema, handler, attributes, servername,
sharename, file, path

I use some of these fields for conditional rewriting of the filename.

I realise it is not ideal, but it will have to do me for now.

I’m happy to be involved in further discussion and/or provide my
“special goodness” parser for others to use.

Sam