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: ** 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. 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? 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.

I am trying to populate the Finder comment field from extendedAttributes with the code bellow but it doesn't work. Any idea why ? var extendedAttributes: [String : Data] { var attrs = [String: Data]() let comment = self.caption do { let xmlPlistData = try PropertyListSerialization.data(fromPropertyList: comment as Any, format: .xml, options: 0) attrs["com.apple.metadata:kMDItemFinderComment"] = xmlPlistData } catch { NSLog("Error during plist conversion: \(error)") } return attrs }

In the context of a FPUIActionExtensionViewController module the prepare method is defined like this: override func prepare(forAction actionIdentifier: String, itemIdentifiers: [NSFileProviderItemIdentifier]) { So you would expect the itemIdentifiers list to be the item identifier but instead it is a list of the internal fileprovider IDs like: __fp/fs/docID(6595461) So this is a bit problematic because the only way to recover the ID is by using getUserVisibleURL to get the path which is not great. Is there a better way ? Am I missing something ? Thanks,

Dear Apple engineers, Is it possible to make a fileprovider cloud volume mount path independent of the user's home folder in order to have constant path across desktop clients when files are referenced / placed by applications like Adobe Creative Cloud ? Ideally mount or link the fileprovider cloud volume under /Volumes Thanks,

I am trying to sync some metadata fields via NSFileProviderItem extendedAttributes and have been successful when using arbitrary tag names prefixed by "#S" This is good but pretty much useless as those fields won't be indexed by Spotlight and won't be displayed in Finder In order to have my fields displayed in Finder I am attempting to return the com.apple.metadata fields but they seem to be all systematically ignored with or without sync suffix. This is really a big limitation and surprising given the fact that the tagData call works beautifully to synchronised keywords that are then populated in the extended attributes and indexed by Spotlight. One more drop in the bucket of unanswered / undocumented questions in this forum ... Thanks for any help.

Hi there, Anybody knows a way to make the main Finder icon as well as folder emboss icon dynamic per NSFileProviderDomain ?