Exact meaning of NSURLBookmarkCreationMinimalBookmark

What does this value imply on macOS and iOS?

Well there is no NSURLBookmarkResolutionMinimalBookmark. But NSURLBookmarkCreationMinimalBookmark is documented to produce "a smaller bookmark that can be resolved in fewer ways".

(Note: it's worth keeping some Objective-C in your project just so you can paste in these symbols and then do "jump to definition". Sometimes the Objective-C headers have documentation that isn't available elsewhere. That's not true in this case, but it's an important thing to remember.)

There are some additional resolution options that allow resolution without a UI or without mounting a volume. So perhaps one or more of these options isn't possible for a minimal bookmark.

Are iOS bookmarks always security scoped?

Apparently.

Does the minimal enum imply security scoped bookmarks? Is 0 a valid value to bookmarkDataWithOptions, and does that give an even less scoped bookmark than NSURLBookmarkCreationMinimalBookmark`?

This URL bookmark API reminds me a lot of the old Grand Central Dispatch API. The more I learned about it, the more confused I got.

However, there was always an alternative to GCD. I'm seriously leaning towards ripping out all use of URL bookmarks and avoiding any feature that would require them.

We are also using NSURLBookmarkCreationWithoutImplicitSecurityScope on both iOS and macOS, to avoid any implicit resolution of bookmarks we resolve, so that we can explicitly control access by explicit calls to start/stopAccessing.

Apparently, you should never use that.

(https://mothersruin.com/software/Archaeology/reverse/bookmarks.html provides some really interesting insights, but doesn't discuss the minimal bookmarks.)

While interesting, I strongly recommend avoiding anything from that. That page was last updated in July, and these URL bookmarks have changed significantly since then. The behaviour is even changing in 26.2.

Thanks Etresoft!

My assumption was that NSURLBookmarkCreationWithoutImplicitSecurityScope would create a bookmark that, when resolved via NSURLBookmarkResolutionWithoutImplicitStartAccessing, would ensure that the initial access count of the resource was 0.

The goal is to ensure that my own balanced pairs of startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource on the resulting URL will never leak kernel resources due to unbalanced implicit accesses that I've somehow opted in to.

Is NSURLBookmarkResolutionWithoutImplicitStartAccessing perhaps independent of how the bookmark is created, and no the resolution-side of NSURLBookmarkCreationWithoutImplicitSecurityScope ?

If NSURLBookmarkCreationWithoutImplicitSecurityScope and NSURLBookmarkResolutionWithoutImplicitStartAccessing are not meant to be used for this case, then what would the equivalent of the NSURLBookmark{Creation,Resolution}WithSecurityScope be for iOS? NSURLBookmarkCreationMinimalBookmark + NSURLBookmarkResolutionWithoutUI ?

Crossing fingers Kevin Elliott, who seems to have deep knowledge about this area, will jump in with some enlightening clarifications ☺️

For reference, this is my creation code:

NSData *bookmarkData = [url bookmarkDataWithOptions:
            NSURLBookmarkCreationWithoutImplicitSecurityScope
        #if defined(Q_OS_MACOS)
            | NSURLBookmarkCreationWithSecurityScope
        #endif
        includingResourceValuesForKeys:nil
        relativeToURL:nil /* app-scoped bookmark */
        error:&error];

and resolving code:

        securityScopedUrl = [NSURL URLByResolvingBookmarkData:static_cast<NSData*>(bookmarkData)
            options:
                NSURLBookmarkResolutionWithoutImplicitStartAccessing
            #if defined(Q_OS_MACOS)
                | NSURLBookmarkResolutionWithSecurityScope
            #endif
            relativeToURL:nil /* app-scoped bookmark */
            bookmarkDataIsStale:&bookmarkDataIsStale
            error:&error];

My assumption was that NSURLBookmarkCreationWithoutImplicitSecurityScope would create a bookmark that, when resolved via NSURLBookmarkResolutionWithoutImplicitStartAccessing, would ensure that the initial access count of the resource was 0.

You know what they say when you "assume"

The goal is to ensure that my own balanced pairs of startAccessingSecurityScopedResource and stopAccessingSecurityScopedResource on the resulting URL will never leak kernel resources due to unbalanced implicit accesses that I've somehow opted in to.

Apparently, they shouldn't be balanced at all anymore. Instead, developers should issue one extra stopAccessingSecurityScopedResource to release the implicit startAccessingSecurityScopedResource.

Apparently, Instead, developers should issue one extra stopAccessingSecurityScopedResource to release the implicit startAccessingSecurityScopedResource.

That's not my interpretation of that reply at all (in a topic I started, if you notice).

Look a the end of the reply, where the exact flow (after creating the bookmark) is:

From now on, when you need to use the URL, create it with the bookmark data (init(resolvingBookmarkData:options:relativeTo:bookmarkDataIsStale:), and use start/stopAccessingSecurityScopedResource to access it.

So during creation of a bookmark from an incoming URL (file dialog e.g.):

1. start access
2. create bookmark
3. stop access
4. stop access again on macOS to balance implicit access

And on use:

1. Load bookmark
2. start access
3. access resource
4. stop access

My goal with this topic is to determine the right creation options to ensure that when the creation step is done in phase one there is no additional implicit accesses that leak kernel resources, and that when resolve the bookmark in phase two, and are done with the resource (for now), it's back at zero access counts, and no leak of kernel resources.