Getting Windows Cache Manager to work with Dokan.NET
It looks like in order to tap into the cache manager PFILE_OBJECT is required, but IDokanOperations and IDokanFileInfo don't have that exposed.
A pointer to FILE_OBJECT can only be used in kernel mode because that memory is only accessible in kernel mode. Therefore, it cannot be directly exposed to file systems implemented in user mode. Other workarounds would be needed to modify things that needs to be modified in the FILE_OBJECT structure.
So, more specifically, what is it that you want to do with the FILE_OBJECT structure?
@LTRData I just wanted to see if it was possible to tap into Windows caching system as suggested here: https://github.com/dokan-dev/dokany/discussions/1214
E.g. be able to call CcInitializeCacheMap etc
Yes, that would need several changes in the driver to work together with user mode implementation. There was a discussion about it here https://github.com/dokan-dev/dokany/discussions/1047 where @Liryna mentioned some ideas about how it could be implemented. However, as mentioned there, keeping cache invalidation correct and robust is not really a trivial task.
My particular scenario is remote-mounting immutable filesystems ( e.g. a disk image, btw, thanks for https://www.nuget.org/packages/LTRData.DiscUtils.Wim ). So no invalidation should be required except upon the unmount
Windows Cache Manager support can only be implemented in Dokan driver (using CcInitializeCacheMap and other Cc* APIs). It would be the best and does handle cache invalidation if the userland implementation usex the existing API but yes it must do it correctly or data corruption can happen.
The other solution is the userland filesystem implementation to build (read ahead) and own the cache so it can be faster at completing requests. This is not the fastest compared to Windows Cache Manager since Windows Cache Manager in some case IIRC fetch data directly from the cache without even asking Dokan driver. Userland caching has the same complexity with the cache invalidation.
@lostmsu In your scenario if the content is immutable, maybe loading the content in userland memory is acceptable ?
Unfortunately no, the whole scenario is about streaming only what's really needed.