As stated in the "Filter Driver Development Guide" chapter 11.2, FltGetDestinationFileNameInformation should be used in the pre callback for IRP_MJ_SET_INFORMATION, and FltGetTunneledName should be used in post in order to vaidate that the name retrieved in the pre operation was not affected by name tunneling.
When testing with mapped network drives I noticed that FltGetTunneledName always returns a FLT_FILE_NAME_INFORMATION (the result is not NULL), meaning that the name was affected by name tunneling. The initially retrieved name (in the pre callback) correctly pointed to the new (renamed) path. The name returned by FltGetTunneledName was always the initial path (before the rename)
I also noticed that FltGetDestinationFileNameInformation returns the correct path (after the rename) in the post operation callback. But, as stated in the documentation, FltGetDestinationFileNameInformation should be called in the pre operation callback.
Another approach that I've tried was calling FltGetFileNameInformation in the post opereation callback, but this also returned the original (not renamed) path.
What's interesting is that when testing with UNC paths (not mapped network drives) the problem didn't appear.
So far i've tested on windows 10 RS5 and windows 10 RS6.
It looks like you're new here. If you want to get involved, click one of these buttons!
|Upcoming OSR Seminars|
|Writing WDF Drivers||21 Oct 2019||OSR Seminar Space & ONLINE|
|Internals & Software Drivers||18 Nov 2019||Dulles, VA|
|Kernel Debugging||30 Mar 2020||OSR Seminar Space|
|Developing Minifilters||27 Apr 2020||OSR Seminar Space & ONLINE|