I’m trying to understand the intended macOS File Provider behavior when unsynchronised local files exist inside a provider volume that gets deleted. Scenario: A local file is moved (not copied) from a normal filesystem location into a File Provider-backed cloud volume. The provider is disabled/offline or upload is pending, so the file has not yet synchronised to the cloud. The File Provider volume/domain is then deleted from Finder and the deletion is confirmed. In this situation, the unsynchronised file appears to be lost entirely instead of being moved to ~/.Trash. My question is: Why doesn’t macOS preserve unsynchronised local content by automatically moving it to Trash before removing the File Provider domain? From a user perspective, Finder presents the provider volume as a normal filesystem hierarchy, so deleting the volume feels equivalent to deleting a local folder or mounted drive, where local-only files would normally be recoverable via Trash. Is the current behavior expected because: File Provider storage is treated as provider-managed cache rather than canonical filesystem data? Finder delegates deletion semantics entirely to the provider extension? The backing files may not exist as normal files at deletion time? Or are providers expected to implement their own recovery/trash logic? More generally: Is there an Apple-recommended pattern for preventing loss of unsynchronised files during domain removal? Are providers expected to retain pending uploads somewhere recoverable? Is there any supported API for preserving unsynced local items before deleting a domain? I’m asking because this behavior can easily lead to unexpected data loss when users assume Finder trash semantics apply to File Provider volumes.

I’m trying to understand the intended macOS File Provider behavior when unsynchronised local files exist inside a provider volume that gets deleted. Scenario: A local file is moved (not copied) from a normal filesystem location into a File Provider-backed cloud volume. The provider is disabled/offline or upload is pending, so the file has not yet synchronised to the cloud. The File Provider volume/domain is then deleted from Finder and the deletion is confirmed. In this situation, the unsynchronised file appears to be lost entirely instead of being moved to ~/.Trash. My question is: Why doesn’t macOS preserve unsynchronised local content by automatically moving it to Trash before removing the File Provider domain? From a user perspective, Finder presents the provider volume as a normal filesystem hierarchy, so deleting the volume feels equivalent to deleting a local folder or mounted drive, where local-only files would normally be recoverable via Trash. Is the current behavior expected because: File Provider storage is treated as provider-managed cache rather than canonical filesystem data? Finder delegates deletion semantics entirely to the provider extension? The backing files may not exist as normal files at deletion time? Or are providers expected to implement their own recovery/trash logic? More generally: Is there an Apple-recommended pattern for preventing loss of unsynchronised files during domain removal? Are providers expected to retain pending uploads somewhere recoverable? Is there any supported API for preserving unsynced local items before deleting a domain? I’m asking because this behavior can easily lead to unexpected data loss when users assume Finder trash semantics apply to File Provider volumes.

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 ?