Projected File System

https://scorpiosoftware.net/2024/02/20/projected-file-system/

by thunderbong • 2 years ago

70 24 2 years ago

scorpiosoftware.net

ndsipa_pomu• 2 years ago

Reminds me of "fuse" - userspace filesystems for Linux

https://www.kernel.org/doc/html/latest/filesystems/fuse.html

kreetx• 2 years ago

fuse is surprisingly easy to use once you get familiar with it: there is a number of callbacks to file operations you need to provide, and that's it! Very similar to making an HTTP API.

zmj• 2 years ago

This isn't FUSE. It's a thin middle layer to hydrate content into the real filesystem.

threePointFive• 2 years ago

I would love to see this functionality exposed more generally. One thing I thought was cool in ReactOS was the ability to explore the registry as part of the file explorer. Powershell also exposes similar functionality (like the HKLM: drive) but being able to access that through common tools like Explorer would make the Windows internals feel much more approachable.

jakopo87• 2 years ago

It's possible on Windows too using Windows Registry shell extension[0], which uses Windows Shell Namespaces under the hood.

[0] http://www.viksoe.dk/code/regfolder.htm

[1] https://en.wikipedia.org/wiki/Windows_Shell_namespace

knome• 2 years ago

This looks absolutely painful next to FUSE.

t43562• 2 years ago

This would let you implement the UNIX "everything is a file" philosophy on windows.

Although I feel guilty because that's probably more the Plan 9 philosophy. On Linux you get a lot of nice things by having /procfs for example but lots of things aren't files that might be. I've often wondered if a file based interface to dbus wouldn't be very liberating from the scripting point of view for example.

Plan 9 even does sockets via a file based interface and to my eyes it's no more clunky than BSD sockets - but presto, any bash script would be able to open a socket without netcat.

bytK7• 2 years ago

Indeed, bash already has socket access via /dev/tcp/HOST/PORT and /dev/udp/HOST/PORT, which allow opening a socket and reading from/writing to it as if it were an ordinary file.

folmar• 2 years ago

Though this is implemented in bash itself and only works in bash, not in other programs.

ithkuil• 2 years ago

IIRC that only works for clients and can't be used for listening.

Also IIRC there is a bash loadable module that implements server sockets but that can't be relied upon if you're just shipping bash scripts meant to be run without the end user preparing the ground before running it.

blueflow• 2 years ago

This is the new pattern emerging... Linux is the trendsetter and Windows is following. Windows is becoming the underdog.

psd1• 2 years ago

Innovation has never been part of Microsoft's strategy, but believe whatever makes you happy.

muststopmyths2• 2 years ago

Well at least it seems easier than the IFS approach to exposing a foreign filesystem. I suppose if someone wrote a FUSE api wrapper around this it could be even more useful.

poizan42• 2 years ago

It's not a full-blown userspace filesystem like fuse or dokany (which already has a fuse wrapper). The projected file system still needs a local folder where it can place copies of files from the "backing store". E.g note the Remarks section at https://learn.microsoft.com/en-us/windows/win32/api/projecte...

When ProjFS receives the data it will write it to the file to convert it into a hydrated placeholder.

EvanAnderson• 2 years ago

There's some discussion here: https://github.com/microsoft/ProjFS-Managed-API/issues/54

It looks like it's meant to solve a much narrower problem than FUSE.

Edit:

Since you mentioned Dokany[0] I'll also throw out a shout for WinFsp[1] as a similar project, too.

[0] https://github.com/dokan-dev/dokany

[1] https://winfsp.dev/

pdimitar2• 2 years ago

I don't think trying to shove "everything is a file" everywhere is going to work well but let's see what the future holds.

IMO we actually should gradually start moving away from that. It's a leaky abstraction (though granted, our current tooling is pretty strong and excellent about all this so I guess it's a 50/50 here).

jml7c5• 2 years ago

Yeah, the APIs aren't great on either Windows or Unix. I'm reminded of a @fasterthanlime tweet:

Few people know the complete quote: "Everything is a file — the worst possible primitive"

Especially in a multi-core world, you need to know a lot of Unix(/Linux) arcana to write a program that ensures ACID-like properties for files. (And this need applies to almost any program that writes to a file.) If filesystem APIs were redesigned tomorrow, they would be quite different from what we have today.

pdimitar2• 2 years ago

Had no clue of the original quote, hah. Thanks for letting me know! :)

And I especially agree with the multi-core comment. We need filesystems as full-blown ACID databases, like 10 years ago now.

Surely it can't be so difficult to have a K/V store with ACID semantics and give it a filesystem emulation layer so people can use all the normal coreutils like `ls` and `cd` etc. But then also add a little extra API that allows for locking, transactions and all the good stuff?

Will nobody step up?...

londons_explore• 2 years ago

I really wish they could have just called this WinFUSE

duped• 2 years ago

Do you have to enable the feature for this to be used on user machines? Is it persistent across restarts?

It's really annoying that seemingly simple things that have been around forever (this vs FUSE, NFS, freaking symbolic links) are gated behind "pro" features or advanced user workflows. It's very difficult to rely on them as an application developer shipping products to less determined/advanced users.

Projected File System

Related Stories