3 ms·

Having written a shell namespace extension, I now use the concept as a great example of making the wrong abstraction interestingly enough. Shell namespaces are

Having written a shell namespace extension, I now use the concept as a great example of making the wrong abstraction interestingly enough. Shell namespaces are a odd win32 concept rather than a filesystem concept and cause a lot of headaches (read support calls) when people see that they work in explorer, but not from arbitrary applications depending on how they use the underlying APIs. If you're trying to abstract the filesystem with pluggable components... abstract _the filesystem_ with pluggable components. It'd be interesting to now what lead to the architectural decision of wear to cut that abstraction. It feels like a Microsoft team balkanization issue (the explorer team and POs being different from the NT kernel ones, I assume?), but it's near impossible to know without inside knowledge.

bhawks 5y ago
The traditional posix filesystem is yet another leaky abstraction. Inflexible ACLS and metadata, a horrible and confusing consistency story, an inability to reliably / cleanly rename files, interfaces that are painful to implement performantly without surprises, don't even get started on fsync... I just want to create, read, update and delete some resources :)
- monocasa 5y ago
  But at least there I can expect programs run as the same user to see the same files. "Why can I see the files in explorer and not this program I run to use those files?" isn't an answer you have to burn support time on because it's not ultimately implementing an FS layer in special GUI components. It's not that I don't like their FS abstraction (there's a lot of abstractions I don't like; as an engineer that's not an interesting topic for discussion but instead basically expected). It's that they broke their own abstraction a decade later by implementing the multiplextion in a layer totally contrary to what the user expects. Like if FUSE was implemented entirely in Gnome components and anything that used open(2) broke as not seeing the veneer files but you could see them in every system application.
  - teddyh 5y ago
    > Like if FUSE was implemented entirely in Gnome components and anything that used open(2) broke as not seeing the veneer files but you could see them in every system application. Oh, you mean exactly like Gnome GVfs?
    - monocasa 5y ago
      They at least stick a fuse module in too so it exists in the normal filesystem and non gnome apps can work with normal filepaths still. But yeah, agreed that it's also a case of this being implemented at entirely the wrong layer, probably following in the windows shell extension's footsteps blindly.
kevingadd 5y ago
I suspect one reason is that it doesn't make sense for everything in a namespace to actually be a file. For example, making something like Control Panel or My Network namespaces is a cute way to make them browsable in Explorer and similar tools (to find a network host, etc) but making those entries files would be a kind of pointless thing to do - almost every assumption you might make about files wouldn't hold for any of those entries. Of course, as you point out the right abstraction in many cases is an abstract filesystem, and for whatever reason pluggable filesystems aren't really a Windows Thing (though I think they may have been added recently for features like OneDrive and lazy git checkouts). The existence of shell namespace extensions probably stopped that valuable feature from getting put in...

bhawks 5y ago

The traditional posix filesystem is yet another leaky abstraction. Inflexible ACLS and metadata, a horrible and confusing consistency story, an inability to reliably / cleanly rename files, interfaces that are painful to implement performantly without surprises, don't even get started on fsync... I just want to create, read, update and delete some resources :)

monocasa 5y ago
But at least there I can expect programs run as the same user to see the same files. "Why can I see the files in explorer and not this program I run to use those files?" isn't an answer you have to burn support time on because it's not ultimately implementing an FS layer in special GUI components. It's not that I don't like their FS abstraction (there's a lot of abstractions I don't like; as an engineer that's not an interesting topic for discussion but instead basically expected). It's that they broke their own abstraction a decade later by implementing the multiplextion in a layer totally contrary to what the user expects. Like if FUSE was implemented entirely in Gnome components and anything that used open(2) broke as not seeing the veneer files but you could see them in every system application.
- teddyh 5y ago
  > Like if FUSE was implemented entirely in Gnome components and anything that used open(2) broke as not seeing the veneer files but you could see them in every system application. Oh, you mean exactly like Gnome GVfs?
  - monocasa 5y ago
    They at least stick a fuse module in too so it exists in the normal filesystem and non gnome apps can work with normal filepaths still. But yeah, agreed that it's also a case of this being implemented at entirely the wrong layer, probably following in the windows shell extension's footsteps blindly.

kevingadd 5y ago

I suspect one reason is that it doesn't make sense for everything in a namespace to actually be a file. For example, making something like Control Panel or My Network namespaces is a cute way to make them browsable in Explorer and similar tools (to find a network host, etc) but making those entries files would be a kind of pointless thing to do - almost every assumption you might make about files wouldn't hold for any of those entries. Of course, as you point out the right abstraction in many cases is an abstract filesystem, and for whatever reason pluggable filesystems aren't really a Windows Thing (though I think they may have been added recently for features like OneDrive and lazy git checkouts). The existence of shell namespace extensions probably stopped that valuable feature from getting put in...