Public API for in-place on-demand files in an arbitrary existing folder on macOS 13?

Question

Created 3d

Replies 1

Boosts 0

Participants 2

I am implementing a sandboxed macOS sync app using NSFileProviderReplicatedExtension, with a minimum deployment target of macOS 13.

The requirement is for a user to select an arbitrary existing, nonempty APFS directory, for example /Users/example/Documents/SyncExample, and turn its synchronized files into real on-demand items while preserving that directory's original physical path and file-system identity. Moving it into CloudStorage, substituting a symlink or alias, or changing only Finder presentation would not satisfy the requirement.

After the exact file version has been uploaded and verified, the app needs to support safe native eviction and later materialization in that same directory.

The documentation for NSFileProviderManager.import(_:fromDirectoryAt:completionHandler:) describes migration into the system's managed cache, after which the original URL is no longer valid:

https://developer.apple.com/documentation/fileprovider/nsfileprovidermanager/import(_:fromdirectoryat:completionhandler:)

The documented Desktop/Documents and external-volume features do not appear to select an arbitrary subdirectory:

https://developer.apple.com/documentation/Updates/FileProvider

Is there a supported public API that meets this requirement on macOS 13? If not, does a newer macOS version support this for arbitrary existing subdirectories, rather than only known folders or volume placement?

Please point me to the appropriate API and its precise constraints, or clarify the platform limitation. No private APIs, manual dataless flags, or fake placeholders would be used. The directory above is fictional.

Answer 1

DTS Engineer OP

Apple

4h

The requirement is for a user to select an arbitrary existing, nonempty APFS directory, for example /Users/example/Documents/SyncExample, and turn its synchronized files into real on-demand items while preserving that directory's original physical path and file-system identity. Moving it into CloudStorage, substituting a symlink or alias, or changing only Finder presentation would not satisfy the requirement.

What are you actually trying to do here? FileProvider itself doesn't require a particular hard-coded/known path, simply because many cloud services allow the user to choose their own cloud directory. However, importing a directory into FileProvider does modify the state of that directory, as that's simply part of FileProvider's basic implementation.

One thing to understand is what this means:

The documentation for NSFileProviderManager.import(_:fromDirectoryAt:completionHandler:) describes migration into the system's managed cache, after which the original URL is no longer valid:

The original URL is no longer "valid" in the sense that the FileProvider should not be attempting to manipulate the directories contents through the original file system path, as the contents have been moved and manipulated as part of the import process. However, it IS valid in terms of what the user see and how most other apps will access the data.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware