Name provider

Hi,

Am I understanding this correctly:

  • A name provider would only be called from instances above its own
    instance? Except if REQUEST_FROM_CURRENT_PROVIDER flag is set by its
    instance, in which case, it and providers below it are called?
  • The instance passed in is the instance below the provider? (or
    possibly its own instance if the callback has the CURRENT_PROVIDER
    flag?)
  • Even if the FGFNI/FGFNIU request comes for a previously unseen
    stream file object during read/write, when a provider sends FGFNI call
    down the stack, it would never receive a path that it redirected from?
  • Name provider results are seen by minifilters only? I.e. legacy
    filters or user mode apps will not see them?

The reason I’m checking is that I made a test name provider, and I am seeing lower filters returning data to me, that I should not be seeing.
E.g. I am redirecting a folder (reparsing), and still my name generator gets file names of original folders once in a while (which is not from myself obviously, as I never use CURRENT_PROVIDER flag).

Your understanding sounds correct to me with the exception that the Instance passed in is your instance, not the instance beneath you (though your queries will go below you).

Maybe it’s a name from PreCreate that’s poisoning the cache? See the NameChanger sample provider.

Correct, about the instance bit.

I did set DO_NOT_CACHE flag if the call is from pre-create.

But, considering I do reparse, upper filters can call the API in their
pre-create, resulting in “user view” paths to be seen by my name
provider. Good lead :wink:

This stack somewhat explains the problem:

8aed65d8 89b935cf 97a26450 89b7140e 8298afdc fltmgr!FltpCallOpenedFileNameHandler+0x72 (FPO: [Non-Fpo])
8aed65f0 89b61f95 97a26450 89ba918a 974af5d0 fltmgr!FltpCreateFileNameInformation+0x15b (FPO: [Non-Fpo])
8aed6624 89b96ef0 97a26450 8298afdc 974af5d0 fltmgr!FltpGetFileNameInformation+0x6c3 (FPO: [Non-Fpo])
8aed6648 89b97fa1 974af5d0 89ba79f8 974af5d0 fltmgr!FltpGetFileNameFromFileObject+0x198 (FPO: [Non-Fpo])
8aed6660 89b922d6 164af5d0 89ba79f8 974af5d0 fltmgr!FltpGetOpenedFileName+0xf7 (FPO: [Non-Fpo])
8aed667c 89b935cf 974af5d0 8bcef58c 974af5d0 fltmgr!FltpCallOpenedFileNameHandler+0xd6 (FPO: [Non-Fpo])
8aed6694 89b61794 974af5d0 89b7140e 8298afdc fltmgr!FltpCreateFileNameInformation+0x15b (FPO: [Non-Fpo])
8aed66b8 89b61a2d 8bd883dc 00000000 00000000 fltmgr!HandleStreamListNotSupported+0x1fe (FPO: [Non-Fpo])
8aed66ec 89b629a4 974af5d0 97a2f760 82812bd6 fltmgr!FltpGetFileNameInformation+0x15b (FPO: [Non-Fpo])
8aed6724 9179fec2 974b1b68 00000402 8aed6744 fltmgr!FltGetFileNameInformation+0x304 (FPO: [Non-Fpo])
8aed6748 89b92272 821b8008 97a2f760 974b1b68 luafv!LuafvGenerateFileName+0x80 (FPO: [Non-Fpo])
8aed6778 89b980b5 97413978 89ba79f8 97413978 fltmgr!FltpCallOpenedFileNameHandler+0x72 (FPO: [Non-Fpo])
8aed6794 89b98cd0 97413978 89ba79f8 97413978 fltmgr!FltpGetNormalizedFileNameWorker+0x65 (FPO: [Non-Fpo])
8aed67b0 89b935ed 97413978 8bcef584 97413978 fltmgr!FltpGetNormalizedFileName+0x6a (FPO: [Non-Fpo])
8aed67c8 89b61794 97413978 89b7140e 8298afdc fltmgr!FltpCreateFileNameInformation+0x179 (FPO: [Non-Fpo])
8aed67ec 89b61a2d 8bd883c0 00000000 00000000 fltmgr!HandleStreamListNotSupported+0x1fe (FPO: [Non-Fpo])
8aed6820 89b629a4 97413978 974b1b08 89b68fce fltmgr!FltpGetFileNameInformation+0x15b (FPO: [Non-Fpo])
8aed6858 89bd8b8c 974b1b68 00000401 8aed68a8 fltmgr!FltGetFileNameInformation+0x304 (FPO: [Non-Fpo])
8aed68ac 89bdd834 974b1b68 8aed6960 8aed6930 AlfaCW!AlfaFF_GetFileName+0x6c (FPO: [Non-Fpo]) (CONV: stdcall) [g:\projects\alfaff\alfacw\namesup.c @ 41]
8aed6940 89b54291 974b1b68 8aed6960 8aed6988 AlfaCW!CreatePreOp+0x1a4 (FPO: [Non-Fpo]) (CONV: stdcall) [g:\projects\alfaff\alfacw\create.c @ 119]

AlfaCW (my filter) is at 145601, luafs is at 13xxxx, so below me.

Luafs’s FltGetFileNameInformation call should not be going to my driver, should it? Yet it does.
AND with the GET_FROM_CURRENT_PROVIDER flag (which does not make sense, because in my FltGetFileNameInformation call I did NOT set this flag)

Seems weird. What instance is in the callback data passed as LuaFv’s first argument to FltGetFileNameInformation?

Sorry: I have seen only the below case today, and did not notice it was a different stack from the previous ones.
Please disregard this message. I cannot find a delete button.

Please disregard this message.

My bad… that is just a different case, the original message contains
the stack trace with FGFNI, not FGFNIU.

I have seen two different cases with FGFNI now:

  • Luafs passed my own Instance (the one I passed to FGFNI) (see the stack below)
  • Luafs passes a different instance (first message of this thread)
AlfaCW!AlfaCW_GenerateFileName+0x19c (FPO: [Non-Fpo]) (CONV: stdcall)   
[g:\projects\alfaff\alfacw\nameprov.c @ 191]   
bd317540 8549875d 8ac07300 00000000 8ac07300   
fltmgr!FltpCallOpenedFileNameHandler+0x4f (FPO: [Non-Fpo])   
bd317558 85482b21 8ac07300 00000000 8ac046d0   
fltmgr!FltpCreateFileNameInformation+0x79 (FPO: [Non-Fpo])   
bd317588 8549a364 880f7e24 00000000 8ac046d0   
fltmgr!FltpGetFileNameInformation+0x321 (FPO: [Non-Fpo])   
bd3175a8 8549ad0c 8ac046d0 8ac046d0 bd3175d4   
fltmgr!FltpGetFileNameFromFileObject+0x64 (FPO: [Non-Fpo])   
bd3175b8 85497f62 8ac046d0 8ace8778 8ac046d0   
fltmgr!FltpGetOpenedFileName+0x4a (FPO: [Non-Fpo])   
bd3175d4 8549875d 8ac046d0 8ace8778 8ac046d0   
fltmgr!FltpCallOpenedFileNameHandler+0x8a (FPO: [Non-Fpo])   
bd3175ec 85482773 8ac046d0 00000000 8ac046d0   
fltmgr!FltpCreateFileNameInformation+0x79 (FPO: [Non-Fpo])   
bd31760c 854828c7 8bc863d4 00000000 00000000   
fltmgr!HandleStreamListNotSupported+0x125 (FPO: [Non-Fpo])   
bd31763c 85482fa3 c00000bb 8f09c000 bd3176c0   
fltmgr!FltpGetFileNameInformation+0xc7 (FPO: [Non-Fpo])   
bd317664 854a0d14 00ce8780 00000402 bd3176c0   
fltmgr!FltGetFileNameInformation+0x12b (FPO: [Non-Fpo])   
bd317690 a3993952 8ace8780 00000402 bd3176c0   
fltmgr!FltvGetFileNameInformation+0x40 (FPO: [Non-Fpo])   
bd3176ac 85497f27 91bd0000 8ac073d0 8ace8780   
luafv!LuafvGenerateFileName+0x58 (FPO: [Non-Fpo])   
bd3176dc 8549ad5c 880ed400 8ace8778 880ed400   
fltmgr!FltpCallOpenedFileNameHandler+0x4f (FPO: [Non-Fpo])   
bd3176f8 8549b505 880ed400 8ace8778 881f4e6c   
fltmgr!FltpGetNormalizedFileNameWorker+0x16 (FPO: [Non-Fpo])   
bd317710 85498765 880ed400 8ace8778 880ed400   
fltmgr!FltpGetNormalizedFileName+0x19 (FPO: [Non-Fpo])   
bd317728 85482773 880ed400 00000000 880ed400   
fltmgr!FltpCreateFileNameInformation+0x81 (FPO: [Non-Fpo])   
bd317748 854828c7 8bc863b8 00000000 00000000   
fltmgr!HandleStreamListNotSupported+0x125 (FPO: [Non-Fpo])   
bd317778 85482fa3 c00000bb 8bdc8000 bd31781c   
fltmgr!FltpGetFileNameInformation+0xc7 (FPO: [Non-Fpo])   
bd3177a0 854a0d14 00ce8780 00000401 bd31781c   
fltmgr!FltGetFileNameInformation+0x12b (FPO: [Non-Fpo])   
bd3177cc 85abaa6c 8ace8780 00000401 bd31781c   
fltmgr!FltvGetFileNameInformation+0x40 (FPO: [Non-Fpo])   
bd317820 85abefe6 8ace8780 bd317964 bd3178bc   
AlfaCW!AlfaFF_GetFileName+0x6c (FPO: [Non-Fpo]) (CONV: stdcall)   
[g:\projects\alfaff\alfacw\namesup.c @ 41]   
bd3178cc 854a1627 8ace8780 bd317964 bd317990 AlfaCW!CreatePreOp+0x1b6   
(FPO: [Non-Fpo]) (CONV: stdcall) [g:\projects\alfaff\alfacw\create.c @   
124]```

My bad… that is just a different case, the fourth message of the thread contains the stack trace with FGFNI, not FGFNIU:
https://community.osr.com/discussion/comment/293655/#Comment_293655

So, in case of Luafs, it passed my own Instance (the one I passed to FGFNI)

AlfaCW!AlfaCW_GenerateFileName+0x19c (FPO: [Non-Fpo]) (CONV: stdcall)
[g:\projects\alfaff\alfacw\nameprov.c @ 191]
bd317540 8549875d 8ac07300 00000000 8ac07300
fltmgr!FltpCallOpenedFileNameHandler+0x4f (FPO: [Non-Fpo])
bd317558 85482b21 8ac07300 00000000 8ac046d0
fltmgr!FltpCreateFileNameInformation+0x79 (FPO: [Non-Fpo])
bd317588 8549a364 880f7e24 00000000 8ac046d0
fltmgr!FltpGetFileNameInformation+0x321 (FPO: [Non-Fpo])
bd3175a8 8549ad0c 8ac046d0 8ac046d0 bd3175d4
fltmgr!FltpGetFileNameFromFileObject+0x64 (FPO: [Non-Fpo])
bd3175b8 85497f62 8ac046d0 8ace8778 8ac046d0
fltmgr!FltpGetOpenedFileName+0x4a (FPO: [Non-Fpo])
bd3175d4 8549875d 8ac046d0 8ace8778 8ac046d0
fltmgr!FltpCallOpenedFileNameHandler+0x8a (FPO: [Non-Fpo])
bd3175ec 85482773 8ac046d0 00000000 8ac046d0
fltmgr!FltpCreateFileNameInformation+0x79 (FPO: [Non-Fpo])
bd31760c 854828c7 8bc863d4 00000000 00000000
fltmgr!HandleStreamListNotSupported+0x125 (FPO: [Non-Fpo])
bd31763c 85482fa3 c00000bb 8f09c000 bd3176c0
fltmgr!FltpGetFileNameInformation+0xc7 (FPO: [Non-Fpo])
bd317664 854a0d14 00ce8780 00000402 bd3176c0
fltmgr!FltGetFileNameInformation+0x12b (FPO: [Non-Fpo])
bd317690 a3993952 8ace8780 00000402 bd3176c0
fltmgr!FltvGetFileNameInformation+0x40 (FPO: [Non-Fpo])
bd3176ac 85497f27 91bd0000 8ac073d0 8ace8780
luafv!LuafvGenerateFileName+0x58 (FPO: [Non-Fpo])
bd3176dc 8549ad5c 880ed400 8ace8778 880ed400
fltmgr!FltpCallOpenedFileNameHandler+0x4f (FPO: [Non-Fpo])
bd3176f8 8549b505 880ed400 8ace8778 881f4e6c
fltmgr!FltpGetNormalizedFileNameWorker+0x16 (FPO: [Non-Fpo])
bd317710 85498765 880ed400 8ace8778 880ed400
fltmgr!FltpGetNormalizedFileName+0x19 (FPO: [Non-Fpo])
bd317728 85482773 880ed400 00000000 880ed400
fltmgr!FltpCreateFileNameInformation+0x81 (FPO: [Non-Fpo])
bd317748 854828c7 8bc863b8 00000000 00000000
fltmgr!HandleStreamListNotSupported+0x125 (FPO: [Non-Fpo])
bd317778 85482fa3 c00000bb 8bdc8000 bd31781c
fltmgr!FltpGetFileNameInformation+0xc7 (FPO: [Non-Fpo])
bd3177a0 854a0d14 00ce8780 00000401 bd31781c
fltmgr!FltGetFileNameInformation+0x12b (FPO: [Non-Fpo])
bd3177cc 85abaa6c 8ace8780 00000401 bd31781c
fltmgr!FltvGetFileNameInformation+0x40 (FPO: [Non-Fpo])
bd317820 85abefe6 8ace8780 bd317964 bd3178bc
AlfaCW!AlfaFF_GetFileName+0x6c (FPO: [Non-Fpo]) (CONV: stdcall)
[g:\projects\alfaff\alfacw\namesup.c @ 41]
bd3178cc 854a1627 8ace8780 bd317964 bd317990 AlfaCW!CreatePreOp+0x1b6

124]```