Thanks for your answer. Our app supports macOS 10.10 onwards, while the file provider is from macOS 11.0, so any solution is there for an older OS version without using ES or KAUTH framework.
Historically, "file sync services" basically worked in one of three ways:
-
Use Kauth to detect the open() call until the file was downloaded. This had the advantage of being relatively "easy" and the disadvantage of requiring a KEXT and using kauth. Note that the ES auth timeout means that it does NOT work for this use case and, yes, that's intentional.
-
Use a VFS driver, typically using FUSE. This is marginally safer than #1 (since the file system is self-isolated) but quite complex (though FUSE helps) and requires a KEXT.
-
Use a "loopback" SMB server. An SMB server is run on the machine which the machine mounts. The SMB server then handles I/O requests using a mix of its own local file cache and downloading data from the network.
Looking at those architectures, I have a comment here:
Working on an app like Dropbox and making a feature like Dropbox offline download,
One thing to understand here is that the "file syncing service" user experience (common to services like Dropbox, iCloud Drive, etc...) is actually caused by the very specific details of the original Kauth implementation. That specific experience can really only be implemented by Kauth or replicated file provider. The other two options above provide similar functionality (presenting a volume which contains a "mix" of local and remote content), but the user experience will NOT be the same.
With that context, my first recommendation would be that you seriously consider increasing your minimum system requirement so that you can use file provider. If older system support is critical, supporting those systems through an "app" solution (where an app presents a list of available content and allows the user to download it) instead of trying to create a "volume/syncing folder" solution.
Implementing ANY of these solutions, including file provider, is a complex problem that's going to require significant development time and testing, so supporting older systems means either doing the work twice (once using the "legacy" technology and then again using FileProvider) or providing an inferior (non-file provider) solution on newer systems.
However, if you're going to implement a legacy solution, then the ONLY approach I can recommend is #3. Both of the other options require KEXTs which are both difficult to implement and VERY difficult to deploy. By contrast, #3 runs as a standard app/daemon without any unusual configuration requirements. Indeed, it's entirely possible for a well-written implementation of #3 to work across a VERY broad system range with very little version-specific code. As far as the system is concerned, it's just mounting an SMB volume, so the only thing that matters is whether or not that SMB server sends and receives what the Mac is expecting.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
