If the CreatePreOp receives a file object whose file name is ?
(an invalid file name, as passing the I/O through returns
STATUS_OBJECT_NAME_INVALID), on Windows 7, it will still get the file
name that matches that pattern!
This is easily observeable via Command Prompt, just type “cd d” and .
Process Monitor and Zezula’s File Spy also exhibit the same file name
output, when ran alone, so it is nothing from our filter.
I traced the IRP_MJ_CREATE and I can see that the file name in the
FltObjects->TargetFileObject is "C:\USers\Dejan\d", but
FltGetFileNameInformation retrieves C:\Users\Dejan\Desktop as the file
name.
That’s a good one…Presumably you’re querying for a normalized name in PreCreate, yes? The problem appears to be that FltMgr trying to normalize the “d*” component by sending a directory query and getting back something that matches. Fixing this correctly would be a big mess due to the fact that the file system is responsible for determining if a particular file name is valid. So FltMgr can’t determine if the name is valid or not unless is tries to open the file name, which is exactly what it’s trying to avoid by doing the directory query.
Do you really need normalized names in PreCreate? I always try to avoid this if I can (and this bug is yet another reason…).
Yes, for create/overwrite (CREATE_IF/OVR_IF/SPRSD) requests I do
require normalized path names.
I did some searching and found that Alex Carp mentioned this is “by
design” 
I know checking for wildcards is easy, but it’s another
thing I need to do, that the FS would have done
Or at least a note in the docs about it (logging a bug/note as we
speak on the DDI Docs Feedback, which, unlike Edit, works in IE).
On 3/31/19, Scott_Noone_(OSR)
wrote:
> OSR https://community.osr.com/
> Scott_Noone_(OSR) commented on Another FltGetFileNameInformation bug
>
> That’s a good one…Presumably you’re querying for a normalized name in
> PreCreate, yes? The problem appears to be that FltMgr trying to normalize
> the “d*” component by sending a directory query and getting back something
> that matches. Fixing this correctly would be a big mess due to the fact that
> the file system is responsible for determining if a particular file name is
> valid. So FltMgr can’t determine if the name is valid or not unless is tries
> to open the file name, which is exactly what it’s trying to avoid by doing
> the directory query.
>
> Do you really need normalized names in PreCreate? I always try to avoid
> this if I can (and this bug is yet another reason…).
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/293253#Comment_293253
>
> Check it out:
> https://community.osr.com/discussion/comment/293253#Comment_293253
>
BTW, the problem arises when I try to reparse such a file open, using
the returned (invalid for this purpose) file name.
E.g. it took me a week to figure why when I used Cmd.exe it kept
listing a different folder than the current one.