On device B otherVersionsOfItem(at:) returns [fileVerB], no sign of fileVerA at this point. It seems that fileVerA is not yet synchronized to device B.
However, I expect that on device B, the system should not call NSFilePresenter’s presentedItemDidGain(_:) before the file from device A has been downloaded, or at least before the fileVerA URL has been created on disk (so that I can then read its contents using NSFileCoordinator).
In presentedItemDidGain I check if the URL passed in is in a conflict state by using 'newVersionURL.isConflict', and it returns true, and then I run the merge. Is this the right way to check for a pending conflict?
[quote='862396022, DTS Engineer, /thread/804253?answerId=862396022#862396022']
Also, after the newer version from the Device A arrives on Device B, does currentVersionOfItem still return fileVerB on device B?
[/quote]
I no longer check for currentVersionOfItem because the system calls presentedItemDidChange (a split second after presentedItemDidGain), and in this method, I assume there’s no conflict, so I don’t run the merge algorithm. Instead, I simply read the file contents, which happen to be fileVerA, and redisplay it.
I noticed that in case of conflict, the system calls presentedItemDidChange then shortly after presentedItemDidGain. So in presentedItemDidChange I always check for conflict using unresolvedConflictVersionsOfItem(at:), and bail out if positive, because I expect to receive a presentedItemDidGain next.
When I receive it, I run the merge then write the resulting file on disk. The system then calls again presentedItemDidChange, I check again for conflict, this time is negative, and I proceed to display the merged file.
I tried to reproduce this, and call 'currentVersionOfItem', but I can’t trigger the case right now, it only happens occasionally.
