[HN Gopher] Projected File System
___________________________________________________________________
Projected File System
Author : thunderbong
Score : 60 points
Date : 2024-02-21 08:13 UTC (1 days ago)
(HTM) web link (scorpiosoftware.net)
(TXT) w3m dump (scorpiosoftware.net)
| ndsipa_pomu wrote:
| Reminds me of "fuse" - userspace filesystems for Linux
|
| https://www.kernel.org/doc/html/latest/filesystems/fuse.html
| kreetx wrote:
| 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.
| threePointFive wrote:
| 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.
| knome wrote:
| This looks absolutely painful next to FUSE.
| t43562 wrote:
| 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 wrote:
| 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 wrote:
| Though this is implemented in bash itself and only works in
| bash, not in other programs.
| meinheld111 wrote:
| The number of unix environments w/o bash available is
| surprisingly small thou
| proaralyst wrote:
| It means you can't just call open('/dev/tcp/blah') from a
| program and get a TCP socket though, unfortunately
| ithkuil wrote:
| 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 wrote:
| This is the new pattern emerging... Linux is the trendsetter and
| Windows is following. Windows is becoming the underdog.
| psd1 wrote:
| Innovation has never been part of Microsoft's strategy, but
| believe whatever makes you happy.
| muststopmyths wrote:
| 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 wrote:
| 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 wrote:
| 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/
| pdimitar wrote:
| 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 wrote:
| 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.
| londons_explore wrote:
| I really wish they could have just called this WinFUSE
___________________________________________________________________
(page generated 2024-02-22 23:02 UTC)