Windows Features & The Projected File System [Developer’s Take]
Here is another great article from Jacques Bensimon!
A recent How-To Geek article by Chris Hoffman entitled “Windows 10 Is Only Making Windows Fragmentation Worse” crystalized for me a growing sense of unease I’d been having about new features constantly being added to Windows 10 via the “Semi-Annual Channel” (as compared to “Long Term Service Channel” builds that provide feature stability akin to that of previous Windows versions): as an occasional developer of system utilities in the course of client engagements, I’m not so much concerned here about new applets being introduced, or existing applets acquiring new capabilities or being recast as UWP (Metro/Modern/Store) apps, but rather about new (and sometimes powerful) API functionality becoming available in a new Windows build but never becoming available (say via Windows Update) in the increasingly large number of prior builds still found in the wild. Except under highly targeted circumstances, is there any point to my taking advantage of API functions that I know to be absent from most Windows installations? Or to put it philosophically, if an API function only exists in a small subset of Windows machines, does it exist at all?
A perfect example of this is the “Projected File System” feature introduced recently in Microsoft Windows 10 Build 1809: as described in the linked article, it allows an application to “project” data (that has a structure consisting of or resembling a folder & file organization) into the local file system, making it appear as folders and files under a selected root folder. Although the “cute” example provided is a read-only projection of the Registry into the file system (whereby keys and subkeys are folders and values are files – more on that below), I can see such a capability being of great use to present a local view of a remote file repository. The development of the Projected File System is somehow tied to Microsoft’s use of huge GitHub repositories and the desire to make them locally accessible without involving massive data transfers (see the related Git Virtual File System), but in this age of ubiquitous cloud storage providers, one can surmise that this capability could be of great use to developers at DropBox, Box, Citrix (ShareFile), Amazon , Google , etc., including Microsoft itself (OneDrive), all of whom currently have to either roll their own remote file system “drivers” or incorporate third-party libraries (such as Callback Technologies’ CBFS products) into their Windows apps. But this of course can’t and won’t happen until the Projected File System is available in the vast majority of Windows installations. [Note also that the feature doesn’t seem to be available in Windows Server 2019, which is also Build 1809, so it couldn’t be used in RDS deployments, and I’m guessing that it therefore isn’t present in Windows 10 LTSC 2019 either – I’ll note it in the comments if I find out otherwise].
But enough moaning! As long as I was on the subject, I thought I’d compile and make available Microsoft’s above-mentioned Projected File System sample program, RegFS (x64 only), strictly for the fun of it.
To see it in action, run RegFS.exe root_folder_path in a console window, for example RegFS C:\Registry (the selected root folder need not exist in advance). As shown in the screenshot below, the console window will thereafter be populated with trace information about the functions being called (instructive to programmers) while you navigate the Registry tree in File Explorer (or any other program that can browse the file system, including another console window). You can use Notepad to view the contents of any Registry entry, presented as a file by the RegFS provider.
Note: Remember that this is a (in this case thankfully read-only) projection of the Registry into the file system. At no point are the entire contents of the Registry recreated as complete folders and files on disk – only the entries (i.e. files) that you actually open (like “FontSmoothing” in the screenshot) have their contents instantiated on disk (I adore the term Microsoft chose for this, the almost poetic “hydrated”). Once you close the RegFS provider (by pressing Enter in the original console window), only the entries/files that have been ♥hydrated♥ will remain, along of course with all their parent folders. You can safely delete the entire root folder (C:\Registry in this example) when you’re done playing.
If you get the following error message when you attempt to run RegFS.exe, you haven’t yet added the Projected File System feature to your Windows installation (which of course requires that you be running at least Build 1809):
Okay, fun’s over. Back to work!