It's not possible to intercept a "write" request to a projected file

[psxvoid]

Hi,

It seems like we cannot use ProjFS for purposes like ramdisk because ProjFS is always projecting files to a local file system on write. Is that correct?

May we expect an expansion of this API in the future in order to provide such capabilities?

For full context you may refer to this question on stackoverflow: Windows Projected File System read only?

My understanding is accumulated in this answer.

[TanninOne]

I too found this limitation of projfs quite surprising and one could argue the name "projected file system" is misleading, it's more of a lazy/on-demand cloning/import api. Its use seems to be limited to "using the local filesystem as a cache for slow backing stores".

Sure, the "project the registry onto the filesystem" sample is cute but what is it good for if its read-only? You can't do ramdisk, you can't do transparent encryption/decryption, transparent compression/decompression, unionfs-equivalent, ... If you look at examples of how fuse is being used (https://en.wikipedia.org/wiki/Filesystem_in_Userspace#Operation_and_Uses), most of them aren't possible or at least not practical with ProjFS. Fuse was introduced into Linux ~15 years ago. Now Windows releases something similar but it can only do a fraction.

Why Microsoft, just - why? When you already have a filter driver in the operating system that delegates FS operations to users space, why cripple it through a restrictive API? Feels like a wasted opportunity. It seems like a typical Microsoft thing. The approach wasn't "hey, userspace filessystems seem to be neat, lets have an open api and lets see what developers can come up with!", no they went: "We (MS) need an optimization for our humongous git repos, lets solve that exact problem." Even after all the "Microsoft is now changed, we do open-source and stuff" its processes are still more about accomodating their own products and not about making Windows a more powerful/flexible system in general.

Sorry, pretty sure this repo is not the right place to discuss/rant about this but since projfs itself doesn't seem to be open source (again: why?) not sure where this could be discussed/bemoaned.

[ghost]

@TanninOne : You've summed up all the reasons why "ProjFS" is a heavily Microsoft-specific thing and a really bad idea for anyone else. After I read its announcement blogs, went through its documentation and saw the samples, I am puzzled why it is even being talked about. There are hundreds of things like this (bigger and smaller) that are used within MS, they don't talk about those, so why this? Puzzling.

[cgallred]

@psxvoid your understanding as laid out in the StackOverflow thread is correct. ProjFS is not a replacement for FUSE, nor is it positioned as such. It is explicitly not designed to reflect all file system operations into user mode. As @TanninOne mentioned it was indeed designed in conjunction with VFSForGit. We ended up not using a solution that reflects everything into user mode because that turned out to have unacceptably slow performance.

ProjFS is aimed for scenarios where you have a very large data store and commonly work with a small subset of it, but still may need immediate access to any part of it at any time. It effectively uses the file system as a cache of the projected data. It purposely lacks the UX integration features of Cloud Files for performance reasons, so it is a better fit for cases where the user doesn’t necessarily need to know or care that the files are really coming from somewhere else.

[TanninOne]

Thanks for explaining about the performance issues. I still would have loved something like fuse built-in and maintained by MS themselves but at least now I know you had good reason to go this route with ProjFS.

[psxvoid]

@cgallred, Thanks, that make sense. It would be great to see an optional API as a part of ProjFS that allow "intercept" writes. It may not replace the existing one but "extend" it, so the current flow and performance of VFSForGit would not be affected. However, adding new APIs is always risky in terms of security and most likely require good reasoning.

@TanninOne Agree. Working with an external 'FUSE' libraries may be too much hassle. Once, I was using Dokan but even when it was working it was too unstable and sometimes even caused blue screens. Writing own driver may involve even more hassle - certification issues, working with C/C++ directly, etc. Having something like ProjFS but with more capabilities may give developers a boost for implementing their ideas, making it an easy task. Hover, from the business point of view it's a question whether it be demanded or not.

Probably, the issue should be closed because ProjFS is a part of Windows but not of this library itself, though the library gives a brilliant convenient possibility to use it in C#.

[amenon21]

Hi, Would it be possible to bypass file hydration based on the file operation? Eg. on right click to view properties invokes getFileDataCallBack() and hydrates the file. The process name is explorer.exe and hence cannot block it. Any recommendations?

[cgallred]

@amenon21 there's no way for ProjFS to tell that the high-level operation is a right click in Explorer. The file system operations generated by invoking the properties tab in Explorer are operations that require the file's data to be present. In this case getFileDataCallBack() is invoked because the ProjFS file system filter saw a data read (IRP_MJ_READ). In order to satisfy the read, the data has to be present, so the file has to be hydrated.

[amenon21]

Thanks @cgallred