AFAIK [security-scoped bookmarks are] intended for persisting sandbox extensions across app launches, rather than within a single run of an app.
That’s certainly the standard use case, but I don’t see your use case as particularly weird. Lemme explain some background.
When you get a URL from a user action, like the open panel, that URL contains a security scope [1]. When you call startAccessingSecurityScopedResource()
on it, that gets the security scope from the URL and uses it to create a dynamic sandbox extension for that path [2].
The URL’s security scope is tied to the URL’s path, and that’s why things are failing after the rename. The security scope is also tied to the originating process, so you can’t persist it.
When you create a security-scoped bookmark for the URL, the bookmark records information about the file’s identity. This allows the bookmark to track the file across a rename. It also includes a security scope, but a different type of security scope, one that supports persistence.
When you resolve a security-scoped bookmark, you get back a new URL with a new security scope that’s appropriate for the new path.
So, while security-scoped bookmarks do support persistence, they also act like little security-scoped URL factories. You want the latter and not the former. And that’s fine.
And your case is relatively unusual because you’re dealing with an API, FSEvents, that only works in terms of paths. Most folks in your situation just open the file and leave it open, but that’s not an option for you.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Historically that was stored in the fragment part of the URL — so file:///some/path#SSS
— which was cool because you could actually distinguish between those URLs with and without security scopes. These days it’s store in a private resource value.
[2] The actual rules here are complex because there’s a bunch of implicit security scoping happening, partly as a compatibility measure and partly to support MAC, that is, which relies up reusing a bunch of App Sandox infrastructure in non-sandboxed app. See On File System Permissions for more about MAC.