Multiple items created when single createItem call fails

For a new file creation, we need to throw NSFileProviderError(.cannotSynchronize) but we need the file provider to use our identifier instead of the file provider's default identifier (Say 'fp_{RandomID}').

So, we tried giving the NSFileProviderItem object created with our identifier in the completion handler of the createItem function and set the error field with NSFileProviderError(.cannotSynchronize).

But this would create another item in the finder with a name suffixed with '2'(Say 'FileName 2') but the temporary File Provider Identifier and the filename(Say 'FileName') of this NSFileProviderItem object are the same as the previous one. Only the finder and the URL fetched using FileManager.getUserVisibleURL function shows 'FileName 2'.

  1. Why is this behaviour happening?
  2. Why can't the file provider use the identifier given by the main app?
  3. What is the proper way to throw an error in the createItem function but to use the given custom identifier for the item instead of the FP default identifier so that the FP should use the custom identifier in future references?

Thanks.

Up vote post of Kalidoss Down vote post of Kalidoss
348 views
Posted by
Kalidoss
Reply
Add a Comment

Replies

You cannot provide both an Item and error on the createItem completion handler. Likely the system is marking an error on the original item, and syncing down the item metadata as if it is a different item. Hence the filename bouncing (the " 2" suffix).

The system should be sending you the same identifier on the first, and subsequent, createItem requests. See this excerpt from the header comment for createItem, in NSFileProviderReplicatedExtension.h:

The system is setting the itemIdentifier of the itemTemplate to a unique value that is guaranteed to stay the same for a given item in case the creation is replayed after a crash.

What are you trying to do? Why do you need to maintain state on the item across these calls?

Posted by
clenart
Up vote reply of clenart Down vote reply of clenart
Add a Comment