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.
