Future of kexts and File Provider

[Joel Cretan]

Hello,

My apologies if this has been mentioned somewhere, I couldn't find any reference to it. Since kexts are deprecated and may some day go away, is there a plan to move the macFUSE functionality to the File Provider API? I ask because my small FOSS project[1] is looking at what is required to keep working with the latest Mac OS, and wondering whether it is worth updating our project, if macFUSE may some day not be there for us.

Thanks!

Joel

[1] https://github.com/thejoelpatrol/fusehfs/

[Benjamin Fleischer]

Hi Joel,

File Providers are no file systems. In simple terms, File Providers are a plugin to sync files more or less transparently and store them buried in the the user's home directory. There is no (virtual) volume. macFUSE on the other hand allows you to write full-featured file systems. The File Provider framework lacks many features that macFUSE relies on. Therefore it is not possible to implement macFUSE using File Providers.

• File Providers are tailored to a very specific use case and this is keeping a local copy of your personal files in sync with a cloud storage service.
  
  
• File providers do not support common use cases like transparent encryption or decryption. In the File Provider context your files will always be stored unencrypted.
  
  
• File Providers don't support streaming file content. So if you want to play a movie file stored in the cloud, the complete file needs to be downloaded first before it can be played. In case of macFUSE, playback starts almost instantly because file content can be streamed.  Appending a couple of bytes to a large file on a macFUSE volume means you will just have to download and upload a couple of bytes of the file. Using File Providers the whole file needs to be download and then uploaded again.
  
  
• File Providers are not intended for mounting a volumes in order to access some files real quick and then unmounting the volume again. There is a significant overhead due to File Providers creating local placeholder files for all remote files. In fact, there is no unmount button in Finder for File Providers.
  
  
• It would not be possible (or make sense) to build local file systems like NTFS or even network file systems using the File Provider API.
  
  
• Dealing with conflicts can be hard using File Providers. In case of macFUSE every write is synchronous. This means you know exactly which range of the file has changed and you can push the changes to your backend (and notify other hosts of the changes) synchronously. This is not supported by File Providers. With File Providers you receive a callback after the file has been changed by the user. You don’t know which part of the file has changed and you have no way of performing any locking while the file is being modified.

These are just a few differences. There are more.

TL;DR 

The macFUSE functionality cannot be moved to the File Provider API. macFUSE is more versatile than File Providers. File System kernel extensions have not been deprecated by Apple, yet. I expect Apple to release a new user space API for developing full-featured file systems. I will do my best to update macFUSE to use this new API instead of the old kernel API as soon as the new API becomes available.

Best regards,

Benjamin

--
You received this message because you are subscribed to the Google Groups "macFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osxfuse-group/CAErWVPdRD5JYorME7rW5ZY5kzhEX7%3DCb-j_8r-qJQfgZGQAbFQ%40mail.gmail.com.