What I find pretty strange is that the NSFileProviderCustomAction performAction call in the main fileprovider extension receives the right itemIdentifier while the prepare call in the FPUI module receives __fp/fs/fileID... IDs which are useless.
So, I spent some more time looking into this and the difference is basically caused by the context they're called in. The "__fp/fs" ID your UI extension receives is the "broader" format that the broader system uses to track file provider items, and it's what's passed into your UI extension because it's the only ID the Finder has access to.
Conversely, the reason you get a different identifier here:
What I find pretty strange is that the NSFileProviderCustomAction performAction call in the main fileprovider extension receives the right itemIdentifier while the prepare call in the FPUI module receives __fp/fs/fileID... IDs which are useless.
...is (basically) that the "conversion" into your workingSet ID happened earlier when the action was originally transferred into your file provider extension.
And yes, you are correct that this is indeed the ID I am using with the getUserVisibleURL to get the path but evidently it seems that it might be able to work with both kinds of IDs.
Yes. There are actually different code (one is SPI) paths involved with the different ID types, but getUserVisibleURL handles both.
And, yes, you're right that isn't the most elegant architecture.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware