The macOS file provider framework caches the NSFileProviderItem snapshot it received from the extension at enumeration time. When the extension's view of an item changes between app versions — new userInfo keys, fixed predicates, corrected contentPolicy derivation, etc. — the framework does not re-query items it already holds. The cached snapshot stays stale until something forces a re-import.
Two concrete cases already on file illustrate the same underlying problem:
Case A — 34.0.0: new userInfo keys for custom actions
#10057 ("Open in browser") and #10060 ("Copy internal link") added displayOpenInBrowser / displayCopyInternalLink to each item's userInfo, gated by the activation rules in FileProviderExt/Info.plist. After upgrading to 34.0.0, items already enumerated under the previous release keep their old userInfo in the framework's cache, and the new context-menu actions never appear on the entire pre-existing set.
Case B — 33.0.6: contentPolicy inheritance fix
#10054 ("Always Keep Downloaded Inheritance inconsistent") reports that when a "keep downloaded" folder receives a new file from the web interface, the new file is not flagged as inheriting the pinned state. Item.contentPolicy is derived from metadata.keepDownloaded. Fixing the inheritance derivation in 33.0.6 is necessary but not sufficient as an example of this broader pattern: items already enumerated under the buggy logic will keep their stale contentPolicy (and the related displayKeepDownloaded / displayAllowAutoEvicting / displayEvict flags, which depend on the same metadata) in the framework's cache. Without a forced re-import, the fix doesn't actually reach the affected items on the user's machine.
Why signalEnumerator(for: .workingSet, …) is insufficient
The extension already calls it after account setup. It triggers enumerateChanges(from:) against the last sync anchor and only reports new / changed / deleted items — it does not force the framework to re-fetch items it already holds. Neither Case A nor Case B is solved by it.
Why a general mechanism is needed
Both cases are the same problem in different disguises: a NSFileProviderItem-derived property changed between versions for items the framework already has. Every future release that touches userInfo, contentPolicy, fileSystemFlags, capabilities, or any other property derived freshly from the database will hit this again. Patching it per-release is not sustainable.
After any app update — major, minor, or patch — the file provider framework should re-query items that were already enumerated, so the freshly computed NSFileProviderItem properties reach the system without depending on the user editing the affected items by hand.
Scope
- All macOS file provider users on every future app update that changes
NSFileProviderItem-derived properties for items already enumerated.
- The two cases above are the immediate triggers; the goal is to stop this class of bug from recurring once per release.
Related
The macOS file provider framework caches the
NSFileProviderItemsnapshot it received from the extension at enumeration time. When the extension's view of an item changes between app versions — newuserInfokeys, fixed predicates, correctedcontentPolicyderivation, etc. — the framework does not re-query items it already holds. The cached snapshot stays stale until something forces a re-import.Two concrete cases already on file illustrate the same underlying problem:
Case A — 34.0.0: new
userInfokeys for custom actions#10057 ("Open in browser") and #10060 ("Copy internal link") added
displayOpenInBrowser/displayCopyInternalLinkto each item'suserInfo, gated by the activation rules inFileProviderExt/Info.plist. After upgrading to 34.0.0, items already enumerated under the previous release keep their olduserInfoin the framework's cache, and the new context-menu actions never appear on the entire pre-existing set.Case B — 33.0.6:
contentPolicyinheritance fix#10054 ("Always Keep Downloaded Inheritance inconsistent") reports that when a "keep downloaded" folder receives a new file from the web interface, the new file is not flagged as inheriting the pinned state.
Item.contentPolicyis derived frommetadata.keepDownloaded. Fixing the inheritance derivation in 33.0.6 is necessary but not sufficient as an example of this broader pattern: items already enumerated under the buggy logic will keep their stalecontentPolicy(and the relateddisplayKeepDownloaded/displayAllowAutoEvicting/displayEvictflags, which depend on the same metadata) in the framework's cache. Without a forced re-import, the fix doesn't actually reach the affected items on the user's machine.Why
signalEnumerator(for: .workingSet, …)is insufficientThe extension already calls it after account setup. It triggers
enumerateChanges(from:)against the last sync anchor and only reports new / changed / deleted items — it does not force the framework to re-fetch items it already holds. Neither Case A nor Case B is solved by it.Why a general mechanism is needed
Both cases are the same problem in different disguises: a
NSFileProviderItem-derived property changed between versions for items the framework already has. Every future release that touchesuserInfo,contentPolicy,fileSystemFlags, capabilities, or any other property derived freshly from the database will hit this again. Patching it per-release is not sustainable.After any app update — major, minor, or patch — the file provider framework should re-query items that were already enumerated, so the freshly computed
NSFileProviderItemproperties reach the system without depending on the user editing the affected items by hand.Scope
NSFileProviderItem-derived properties for items already enumerated.Related
userInfokey)userInfokey)contentPolicy)