6 ms·

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 dispatc

by duped 3y ago

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).

Groxx 3y ago
Does https://osxfuse.github.io/ https://osxfuse.github.io/ cover this? Or is there some fundamental issue? (beyond "it's not built in")
- skissane 3y ago
  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
  - ranger_danger 3y ago
    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/MacFUSE-SinghInterview/index.html http://preserve.mactech.com/articles/mactech/Vol.23/23.03/Ma...
    - skissane 3y ago
      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
      - ranger_danger 3y ago
        What about the File Provider API?
        skissane 3y ago
        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.
        skissane 3y ago
        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
  - w10-1 3y ago
    > it makes a lot of assumptions which makes it effectively unusable for other use cases What use-cases are foreclosed and why?
- duped 3y ago
  Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn't provide an API for this natively.
  - skissane 3y ago
    > fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understand why Apple won’t. Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?
    - nine_k 3y ago
      > why don't they It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces. Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a specialist OS completely controlled by Apple, with a few companies like Adobe and Ableton licensing access to its internals.
      - skissane 3y ago
        Apple used to be a lot more developer-friendly company. It is part of what got them where they are now - the fact that so many developers use Macs, which in turn encourages business software vendors to support Macs Stuff like this is of little interest to ordinary users (at least not directly), but appeals to developers By de-emphasising the developer is experience, they are undermining one of the factors that got them to where they are today
      - 3y ago
stuaxo 3y ago
I want stuff to work like ZipMagic did in the early 90s/ early 2000s. You could cd into zip files, they would act as directories and files at the same time. I seem to remember Linus saying a file could act like a directory in Linux a long time ago too. Though I don't think Linux has filters for the filesystem like Windows does so implementation might be more tricky.

by duped 3y ago

Groxx 3y ago

Does https://osxfuse.github.io/ https://osxfuse.github.io/ cover this? Or is there some fundamental issue? (beyond "it's not built in")

skissane 3y ago
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
- ranger_danger 3y ago
  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/MacFUSE-SinghInterview/index.html http://preserve.mactech.com/articles/mactech/Vol.23/23.03/Ma...
  - skissane 3y ago
    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
    - ranger_danger 3y ago
      What about the File Provider API?
      - skissane 3y ago
        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.
        skissane 3y ago
        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
- w10-1 3y ago
  > it makes a lot of assumptions which makes it effectively unusable for other use cases What use-cases are foreclosed and why?
duped 3y ago
Well that requires a kext so it's a nonstarter, and fuse-t uses NFS which is extremely janky and unreliable on MacOS. The fundamental issue is that macOS doesn't provide an API for this natively.
- skissane 3y ago
  > fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understand why Apple won’t. Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?
  - nine_k 3y ago
    > why don't they It would make macOS more of a general-purpose OS, would increase the amount of functionality from which third parties would benefit, but Apple themselves would likely not. That would increase the number and variety of tech support requests, ever so slightly but still, and would introduce a few new attack surfaces. Instead, Apple's strategy is to tighten the macOS more and more, and turn it into a specialist OS completely controlled by Apple, with a few companies like Adobe and Ableton licensing access to its internals.
    - skissane 3y ago
      Apple used to be a lot more developer-friendly company. It is part of what got them where they are now - the fact that so many developers use Macs, which in turn encourages business software vendors to support Macs Stuff like this is of little interest to ordinary users (at least not directly), but appeals to developers By de-emphasising the developer is experience, they are undermining one of the factors that got them to where they are today
    - 3y ago

stuaxo 3y ago

I want stuff to work like ZipMagic did in the early 90s/ early 2000s. You could cd into zip files, they would act as directories and files at the same time. I seem to remember Linus saying a file could act like a directory in Linux a long time ago too. Though I don't think Linux has filters for the filesystem like Windows does so implementation might be more tricky.