NSFileProviderPartialContentFetching and high-latency API calls

I am adding NSFileProviderPartialContentFetching support to an existing NSFileProviderReplicatedExtension. My backend has a high "Time To First Byte" latency (approx. 3 seconds) but reasonable throughput once the connection is established.

I am observing a critical behavior difference between Partial Content Fetching and standard Materialization that causes sequential reads (e.g., dd, Finder copies, Adobe apps) to fail with timeouts.

The Scenario: I have a 2.8 GB file. I attempt to read it sequentially using dd.

**Baseline (Working): Partial Fetching Disabled **

  • I do not conform to NSFileProviderPartialContentFetching.
  • The system triggers fetchContents(for:version:request:completionHandler:).
  • My extension takes 3 seconds to connect, then streams the entire 2.8 GB file.
  • Result: Success. The OS waits patiently for the entire download (minutes) without timing out, then dd reads the file instantly from the local disk.

**The Issue: Partial Fetching Enabled **

  • I add conformance to NSFileProviderPartialContentFetching.
  • The system requests small, aligned chunks (e.g., 16KB or 128KB).
  • My extension fetches the requested range. This takes ~3 seconds due to network latency.
  • The first few chunks succeed, but shortly after, the operation fails with Operation timed out.
  • It appears the VFS kernel watchdog treats these repeated 3-second delays during read() syscalls as a stalled drive and kills the operation.

**My Questions: **

  1. Is there a documented timeout limit for fetchPartialContents completion handlers? It seems strictly enforced (similar to a local disk I/O timeout) compared to the lenient timeout for full materialization.
  2. Is NSFileProviderPartialContentFetching inherently unsuitable for high-latency backends (e.g., cold storage, slow handshakes), or is there a mechanism to signal "progress" to the kernel to reset the I/O watchdog during a slow partial fetch?
  3. Does the system treat partial fetching as "Online/Direct I/O" (blocking the user application) whereas full fetch is treated as "Offline/Syncing" (pausing the application), explaining the difference in tolerance?

Any insights into the VFS lifecycle differences between these two modes would be appreciated.

NSFileProviderPartialContentFetching and high-latency API calls
 
 
Q