Replicated File Provider: supported download representation for a directory-backed package

Question

Created 18h

Replies 1

Boosts 0

Participants 1

We implement NSFileProviderReplicatedExtension. A package item has a content type conforming to UTType.package, with a directory and ordinary nested members in remote storage. The system requests contents for the package root. What exact representation should the extension pass to the completion handler of fetchContents(for:version:request:completionHandler:) to materialize that package?

The selected macOS SDK's NSFileProviderReplicatedExtension.h, line 347, states:

must be a regular file on the same volume as the user-visible URL.

The complete ownership comment and method declaration are in FileProvider.framework/Headers/NSFileProviderReplicatedExtension.h, lines 314–416. The current method documentation describes same-volume temporary content, ownership transfer and matching the returned content version.

For a directory-backed package, is a reconstructed directory URL in the manager-provided temporary location a supported exception to the regular-file requirement? If so, please identify the applicable contract and required returned item metadata, including content type and version. If it is not supported, what documented API sequence delivers the package's directory contents? We need to preserve the existing directory representation; we are not asking for an archive convention or a storage-format change.

Verified development environment:

macOS 27.0.1, build 26A434.
Xcode 27.1, tool build 27A9275.
Selected macOS SDK reports version 27.0.

The proposed isolated test host also reports macOS 27.0.1 (26A434); its developer tools have not been inspected.

Observed behavior and limits:

Installed callback records show our extension returning NSFileProviderError.cannotSynchronize before handing any content URL to the system. This is our current refusal, not evidence that macOS rejected a directory URL.
The actual requestedVersion arguments were not captured. Native cached version values do not establish those callback arguments.
The isolated directory-URL handoff test has not run. OS acceptance or rejection of that handoff on the environment above is therefore not observed.

The planned minimal reproduction uses one small synthetic package containing a nested directory, a file with known bytes and an empty member, plus one ordinary-file control. In an isolated development location, we will allow system-initiated fetches, record the actual callback arguments and completion values, and verify the resulting directory structure and bytes. No customer documents, paths, identifiers or private archives are needed. The contract question above can be answered independently of that pending runtime observation.

Answer 1

cre8ivebeast OP

17h

The isolated test described above has now completed on macOS 27.0.1 (26A434), with a normally signed replicated extension.

We used a synthetic RTFD directory package with known text, a nested directory, a zero-byte file and an empty directory, plus a regular-file control. Both uploaded successfully. We then evicted only those fixtures through NSFileProviderManager and verified that both were dataless before selecting Finder's Download Now.

The system initiated a fetch for the package root. The represented item type was com.apple.package, and the actual requestedVersion was nil. Our extension reconstructed the authenticated members in the manager-provided, same-volume temporary location and passed the directory URL to the fetch completion. The returned item's content version represented those same members.

The native fetch completed without error. Both items were materialized before verification read their contents. Every file's SHA-256 matched its retained source; nested structure, the zero-byte file and the empty directory were preserved. The regular-file control also matched. No archive representation or special testing entitlement was used.

This establishes the observed behavior for that synthetic current-version request on this OS. It does not establish an API guarantee or explain the SDK's regular-file wording. Is returning this directory URL a supported package handoff? If so, which contract governs it, including content type, version and ownership requirements? We would like to distinguish supported behavior from an implementation detail before relying on it more broadly.