Post

Replies

Boosts

Views

Activity

FileProvider conflicts: how to have a rename or move operation win when an item is deleted remotely?
Using the File Provider API on macOS, I would like to ensure that renaming or moving an item locally wins when the same item is conflictingly deleted remotely. The default behavior seems to be that the delete wins in these two scenarios (compared to local edits, where the item is recreated in response to the conflict (createItem is called following the enumeration of the remote deletion)). Is there a way for my file provider to indicate that the system should recreate the now modified item following my handling of the deletion? The intended behavior can be observed with iCloud, by taking your Mac offline and renaming or moving an item. Before bringing the Mac back online, permanently delete the same item from another device. Many thanks.
0
0
401
Oct ’23
-com.apple.CoreData.ConcurrencyDebug 1 not working in FileProvider extensions
I discovered a multithreading mistake in my use of NSManagedObjects recently and was surprised that I wasn't alerted to this during development, since I had -com.apple.CoreData.ConcurrencyDebug 1 set under "arguments passed on launch" for my macOS and iOS FileProvider extensions. I confirmed that the expected log stating CoreData: annotation: Core Data multi-threading assertions enabled. is NOT present when running these targets (but does appear as expected on my main macOS and iOS applications). Can anyone advise me on how to get this concurrency debugging functionality to work on my FileProvider extension(s)? Thanks
1
1
753
Aug ’23
FileProviderReplicatedExtension’s modifyItem called immediately following fetchContents’ completion for updates from remote
Hi there, The first time an item is materialized (via fetchContents), the contents are downloaded and we set the contentVersion (to a hash of the content) - no problems here. Once a content change is made remotely, we enumerateChanges and change the contentVersion to ”empty” (Data()). This triggers fetchContents to be called (where we fetch the new content). As soon as we call the completion handler for fetchContents though (now with a new contentVersion (a hash of the new content), we get a call immediately after to modifyContents, with the same contents that we just fetched. This call to modifyContent seems like a bug. how can I prevent it from being called by the system? Thanks for the help!
6
0
671
Jul ’23