Re[2]: Re[2]: Official way to hook GetMappedFileNameW in kernel?

As long as the SOPs for the upper and lower FOs are different, then
you’ll simply end up with 2 sections. That said, in general, you would
like to avoid having caching initialized on the lower FO unless you want
to also control direct access to that file, which you should be anyway.
But again, there are design dependencies here.


Kernel Drivers
Windows File System and Device Driver Consulting http:</http:>

------ Original Message ------
To: “Windows File Systems Devs Interest List”
Sent: 4/18/2016 6:05:24 PM
Subject: RE:[ntfsd] Re[2]: Official way to hook GetMappedFileNameW in

>Thanks again Peter, I’ll study that option.
>If I call CcInitializeCacheMap with the upper FO and update data in
>lower FO, a later call to CcInitializeCacheMap with the lower FO issued
>by the ntfs/fat driver won’t generate a conflict?
>NTFSD is sponsored by OSR
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>To unsubscribe, visit the List Server section of OSR Online at

The goal is simple. I redirect from \src to \dest (may be in different volume) but returning STATUS_REPARSE, I handle the SFO to avoid issues with several apps.

All requests are redirected to SFO with some exceptions to return the correct name.

In earlier version, when caching was disabled, performance drop was noticeable. I believe I had to maintain caching in lower FO to keep simplicity else I may have to handle each IRP separately and do the requests myself to the lower device instead of just modifying TargetFileObject and TargetInstance.