←back to thread

The File Filesystem (2021)

(mgree.github.io)
346 points wegwerff | 2 comments | | HN request time: 0s | source
Show context
RetroTechie ◴[] No.40215710[source]
Useful enough that it should be an OS-level standard feature, imho.

Unix-like OSes allow mounting disk images to explore their contents. But there's many more file formats where exploring files-inside-files is useful. Compressed archives, for one. Some file managers support those, but (imho) application-level is not the optimal layer to put this functionality.

Could be implemented with a kind of driver-per-filetype.

replies(8): >>40215839 #>>40215919 #>>40215928 #>>40216709 #>>40217080 #>>40219626 #>>40225276 #>>40225726 #
duped ◴[] No.40215928[source]
Really what you'd like to see is a way to write the mount command for each file type (do one thing well) and another command to detect the file type and dispatch accordingly (probably similar to the `file` command), all in user space.

The only thing standing in the way of this today is that MacOS doesn't expose a user space file system API. You can do this on Linux, Windows, and BSDs today.

(No, file provider extensions don't cut it, Apple devs who read this, please give us a FUSE equivalent, we know it exists).

replies(2): >>40216593 #>>40220447 #
Groxx ◴[] No.40216593[source]
Does https://osxfuse.github.io/ cover this? Or is there some fundamental issue? (beyond "it's not built in")
replies(2): >>40216747 #>>40216870 #
skissane ◴[] No.40216747{3}[source]
Recent macOS versions do have a general purpose built-in API for user mode filesystems. That API is incompatible with FUSE. The big problem is it is undocumented and you need an entitlement from Apple to use it, and Apple won’t give you that.

Apple do have a publicly available API for cloud file systems (Dropbox-style products), but it makes a lot of assumptions which makes it effectively unusable for other use cases.

Then there are third party solutions like osxfuse. These have the problem that they rely on kernel extensions and Apple keeps on making those harder and harder, and is aiming to get rid of them; plus, they are all now proprietary licensed, albeit often with a free license for open source use.

One approach that does work without any kernel extensions or private APIs is to make your user filesystem an NFS server and then mount that. One competitor to osxfuse does that, but it also is proprietary

replies(2): >>40218540 #>>40227778 #
ranger_danger ◴[] No.40218540{4}[source]
According to the MacFUSE author, their specific approach is not actually undocumented:

> Apple has put it in an umbrella called "unsupported" (in the kernel interfaces section) ... either Apple will not take this interface away, and if they do, it will be to provide a better interface

http://preserve.mactech.com/articles/mactech/Vol.23/23.03/Ma...

replies(1): >>40218833 #
skissane ◴[] No.40218833{5}[source]
Yes, that’s not what I’m talking about though

MacFUSE uses the kernel mode VFS API

I’m talking about the undocumented user mode filesystem LiveFS/UserFS/com.apple.filesystems.lifs API which was added in Monterey (macOS 12), and since Ventura (macOS 13) is used to implement the OOTB FAT and exFAT filesystem support. Using that requires private entitlements (e.g. com.apple.private.LiveFS.connection) which Apple (thus far) won’t give to anyone else

replies(1): >>40218999 #
ranger_danger ◴[] No.40218999{6}[source]
What about the File Provider API?
replies(1): >>40219087 #
1. skissane ◴[] No.40219087{7}[source]
It is designed for the cloud storage use case (Dropbox, Google Drive, etc) - it creates local copies of files and synchs them with remote ones. Not what you want to do in the general case.
replies(1): >>40225941 #
2. skissane ◴[] No.40225941[source]
I take it from the downvotes people think what I said is factually wrong?

If that's the case, I wish someone would point out where I've got it wrong instead of just silently downvoting