3 ms·

> they still haven’t come out with a proper API for implementing local user-space filesystems. They have, it's called a File Provider Extension (0). The major

by duped 3y ago

> they still haven’t come out with a proper API for implementing local user-space filesystems. They have, it's called a File Provider Extension (0). The major downside is that it's extremely limited in what you can provide and it's an extension of the interface on top of APFS and not a proper file system in user space. Frankly, I don't think Apple cares about creating features that would interfere with their own offerings. User space file systems (to them) are for remote storage. Users should use iCloud. Apps that can't shim over iCloud should be file provider extensions. If your app doesn't fit in those boxes then Apple doesn't care about providing the APIs to implement it cleanly on their platform. You can hack it through NFS. (0) https://developer.apple.com/documentation/fileprovider https://developer.apple.com/documentation/fileprovider

comex 3y ago
I'm not sure "interfere with their own offerings" is quite the right framing. It's more about "going beyond their imagined use case". iCloud Drive is a File Provider. Third-party services that want to do the same kind of file syncing as iCloud Drive, and thus compete it with it, can. And there are several highly-popular competitors that have recently moved to File Provider, like Dropbox and Google Drive. But when they did so they had to lose some functionality, like the ability to store data on an external drive [1]. And for the less popular use case of third-party filesystems that aren't just for syncing, File Provider is completely inapplicable. The box covers most of the use cases that most users are using third-party filesystems for. But it's shrink-wrapped around those use cases – no room to invent new ones. [1] https://talk.tidbits.com/t/dropbox-drops-support-for-storing-files-on-an-external-drive-and-onedrive-retains-it/20797 https://talk.tidbits.com/t/dropbox-drops-support-for-storing...
- 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 ago
    I'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.
lxgr 3y ago
File Provider is really an API optimized for "synchronizing file systems" (i.e. network file systems with an explicit local cache, e.g. something like Google Drive or Dropbox). It doesn't seem like a great fit for either network file systems or local file systems: There's mandatory caching, which means everything remote accessed locally is written to disk at least once (completely useless and actively counterproductive for e.g. a local ext4 driver, which is something I dearly miss for fixing Raspberry PI root volumes), and I'm not sure if there's a way to implement remote file locks either.

by duped 3y ago

comex 3y ago

I'm not sure "interfere with their own offerings" is quite the right framing. It's more about "going beyond their imagined use case". iCloud Drive is a File Provider. Third-party services that want to do the same kind of file syncing as iCloud Drive, and thus compete it with it, can. And there are several highly-popular competitors that have recently moved to File Provider, like Dropbox and Google Drive. But when they did so they had to lose some functionality, like the ability to store data on an external drive [1]. And for the less popular use case of third-party filesystems that aren't just for syncing, File Provider is completely inapplicable. The box covers most of the use cases that most users are using third-party filesystems for. But it's shrink-wrapped around those use cases – no room to invent new ones. [1] https://talk.tidbits.com/t/dropbox-drops-support-for-storing-files-on-an-external-drive-and-onedrive-retains-it/20797 https://talk.tidbits.com/t/dropbox-drops-support-for-storing...

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 ago
  I'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.

lxgr 3y ago

File Provider is really an API optimized for "synchronizing file systems" (i.e. network file systems with an explicit local cache, e.g. something like Google Drive or Dropbox). It doesn't seem like a great fit for either network file systems or local file systems: There's mandatory caching, which means everything remote accessed locally is written to disk at least once (completely useless and actively counterproductive for e.g. a local ext4 driver, which is something I dearly miss for fixing Raspberry PI root volumes), and I'm not sure if there's a way to implement remote file locks either.