This is a follow-up to Access sidecar files in a Mac sandboxed app.
Though not covered in the answer there, the Apple docs teach us that to access a "related file" we must use an NSFileCoordinator
for access (ref).
This is a little heavy for my needs, and poses an architectural problem, since the actual file access is in my back-end code, away from the reaches of the Apple library facilities. I don't want to have to use the NSFileCoordinator
for obtaining the related file's content, if I can help it. I don't want to require my users to manually identify the sidecar file either (if nothing else, this would be a bad workflow for batch processing). I just want to tell the sandbox "this is okay, this app can open such-and-such a related File.XYZ after the user chose File.ABC".
For normal file accesses this isn't a problem: using an std::ifstream
to open a file that's been previously selected from an Open panel seems to work for remainder of the app instance's lifetime.
But opening a "related file" seems to be more limited.
Having added a NSIsRelatedItemType
to my app's plist (as indicated in the linked answer), what is the minimal thing I can do in the front-end, presumably immediately after opening the "primary"/requested file, such that I can also later use an std::ifstream
to open a related sidecar file? The documentation seems a little sparse on this subject…
Perhaps my best bet is to perform a one-time prompt for the user to authorise access to the encapsulating directory, and save the resulting entitlement as an app-scoped bookmark (ref) but again that's not quite as transparent as I'd like. It would also be perhaps a little "scary" for users to be confronted with such a request.