3 ms·
My point is their view of a file provider is as a remote file storage API. This is one of the use cases of a file system in user space, but quite different from
by duped 3y ago
My point is their view of a file provider is as a remote file storage API. This is one of the use cases of a file system in user space, but quite different from them generally. Most of the interesting use cases that FUSE covers are completely unsupported by the File Provider API.
And I believe this is because they want anything that might be useful but competitive with the features they provide their users to be hamstrung by the same design contraints of iCloud and APFS.
- lxgr 3y agoI'm not opposed to pointing fingers at Apple when it's justified, but I believe in this case it's really just a matter of priorities. My guess is that the number of users that use remote file storage providers is just much larger than that of users using actual (non-SMB) network or local (non-(ex)FAT) file systems, so they created a kext replacement for that use case first. If anything, the File Provider API levels the playing field between iCloud and third-party remote storage providers, since the neat APFS tricks they can use to implement it would otherwise be unavailable to third party developers. For example, I find Google Drive to be much more well-behaved on File Provider than it ever was when using FUSE (I blame it for some hangs or kernel panics) or SMB (which was more stable, but did not support Spotlight at all). For all the other use cases, I'm hopeful that we'll be seeing a real macOS FUSE sooner rather than later.