I don't mean to hijack the original thread No worries. It's a lost cause. Is there any public documentation of how these two magic directories work and should be handled? I think you're reading it. What is the recommended (CF or POSIX) API to resolve a canonical path in the presence of these paths? In Qt we use realpath if the path exists. Testing realpath /.nofollow/Applications in Terminal it doesn't seem to resolve to /Applications (on 26.1). Good question If the path does not exists, and we need a canonical path (for cache key lookup e.g.), are we expected to manually strip .resolve and .nofollow, the same way we might combine/deal with .. and . ? What is a "cache key lookup"? Are you referencing that 3rd party web site? As Apple engineers often say, that's would be an implementation detail that we shouldn't get involved with. Always good advice, isn't it?

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.

You can use the "isReadable" value from URLResourceValues. However, it sounds like you're not approaching this from the right direction. You should never need to do this in the first place. Your app shouldn't attempt to read random files. It should only attempt to access files that the user has specifically requested. And even then, you shouldn't check readability. That's not reliable. Instead, just try to do what the user asked and report an error if it fails.

Perhaps you should file a Feedback report on Feedback Assistant.

System-wide....Nothing really limits the scope My question is more about the fundamental nature of URL paths. Should we be treating these ".nofollow" components like "." components? For example, in most cases, we don't have to worry much about "." and "..". The system handle them fines, they can be harmlessly standardized away, and they don't occur in the context of NSOpenPanel. They're only an issue when URLs are provided by the user. But we do have to worry about ".nofollow" components now? What do we do with them? Should we be removing that (those, plural?) ".nofollow" component manually? Or will that break something? I'm using an NSToken field to show the user their current location in the file system. I don't want to show ".nofollow" to the user. you probably won't see them with fileReferenceURLs, but that's actually because the fileReferenceURL isn't storing a path at all. That's an interesting idea. However, I'm not too confident in the future of fileReferenceURLs. They aren't even supported in Swift. I use them for one neat little trick, but I have to do it in Objective-C. I suggested testing in Terminal as an easy way to understand how the core system behaves, not to replicate your app’s specific behavior. I wasn't talking about my app's specific behaviour, but, rather, the behaviour of the sandboxed app environment, both when the user has provided access to a given URL and when not. In an earlier app, I wrote a tool just so I could execute system tools from the sandbox to see if they would work or not. Of course, in most cases, those tools aren't "API", so I shouldn't be doing that. Fair enough. But official APIs are really no different. How official APIs are documented to behave and how they work in the sandbox are two different things. And that's one of my primary concerns there. You keep talking in terms of Terminal and Foundation. But in the sandbox, "file:///" and "file:///.nofollow/" are NOT the same thing. I don't even have to talk in theoretical terms about it possibly breaking one day. It's broken right now. If the system resolves a security-scoped URL to "file:///.nofollow/", and I do some UI manipulation to avoid confusing the user, and at some point request "file:///". Will that break? You're talking about Foundation dealing with these paths. But I'm talking about the sandbox. Maybe Foundation does it right but then the sandbox blocks it. You mentioned IPC. That's yet another potential point of breakage. I had to give my launch agent a user-facing entitlement just so I could resolve a security-scoped bookmark. If there is going to be some new type of "special" component to URLs, then it needs to be fully documented. When will developers encounter this? How can they test it? Can it be safely removed? That's really my question here. Can I just treat ".nofollow" like "." and strip it out? That would solve a lot of problems.

My confusion levels have now reached the saturation point. The new ".nofollow" construct effectively "attaches" the no follow flag to the path itself, forcing that flag on all open calls regardless of the actual flag passed in. What is the scope of this new construct? Is this going to be applied to all URLs? Only URLs decoded from a security-scoped bookmark? Only URLs to root directories? What about non-security-scoped bookmarks? What about external drives? What about non-APFS volumes? What about network volumes? In the past, we've been specifically asked to avoid meddling in the affairs of implementation details. But now it seems like we're being thrown in head first. You can see this for yourself in Terminal.app I'm deploying to the Mac App Store with a sandboxed launch agent. Virtually every system-level API I've encountered behaves differently in this environment. I cannot test in Terminal. cd /.nofollow/ ...actually changes to "/". And yes, that's exactly what Terminal.app will do. I assume you mean this is Terminal.app will do in 26.2, correct? I'm not sure what you mean with respect to Foundation behaviours. I assume you are talking about the internals of the Foundation framework, far below anything that we can see. I just did a little test. My app's primary functionality is doing a scan of a user-supplied folder. That folder could be /. Based on previous posts here in the forum, I take the URL provided from NSOpenPanel, save it to a (non-secure) bookmark, and then resolve that bookmark and use that new URL. I don't need a security-scoped URL for this use, so I assumed a non-secure bookmark would provide the same functionality in this case. (I haven't changed my code to issue multiple stopAccessingSecurityScopedResource calls on the implicitly security-scoped original URL, which has also been recommended here in the forums.) But when I change that bookmark to a security-scoped URL, it resolves to a URL of "file:///.nofollow/". It does have the trailing slash in 26.1. Perhaps Foundation is interpreting it differently at a lower level. It most definitely points directly to the empty directory at /.nofollow/, which is not correct. I understand that you've said the bug is fixed in 26.2. But now I'm more concerned about the scope of this new behaviour. I don't really need any security-scoped bookmarks in this app. Perhaps I should just avoid them entirely until this settles down. PS: I now also see the wisdom in accepting the default Xcode deployment targets that include non-zero minor build versions.

The user had mentioned that they use a non-admin account, but I had discarded that fact as irrelevant. After your mention of "take a URL provided from an open panel and launder it through a bookmark before use" I felt inspired to create a non-admin test account and I was actually able to reproduce the issue. On my test rig, where I run 26.1, my user is an Admin user. But on my primary machine, still running Sequoia, I always use a standard user account. I just did a test with my own app. I changed my current laundry code from using a standard bookmark to a security-scoped bookmark. This would have returned nil in 26.0, but in 26.1 it returns a "valid" URL of "file:///.nofollow/" which is an empty directory. Mostly this has been just a minor annoyance because I was dealing with a different, non-scanning feature. But this is the app's primary functionality. Hopefully, this issue can be avoided entirely by avoiding security scoped bookmarks. Can someone at Apple confirm whether this is expected behaviour or what I have to do so that scanning a URL resolved from bookmark data behaves the same as scanning a URL returned from an open panel? +1

A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. There's more information about this here. I don't understand it myself, so I can't do anything other than give you that link. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. I've gotten very confused over these URL APIs recently. I know I've seen them discussed in some of your threads. I don't know if I saw this in one of your threads or not, but I definitely remember seeing advice from a DTS engineer to always take a URL provided from an open panel and launder it through a bookmark before use. If you were doing that with a security scoped bookmark, then it perhaps it would be related. Maybe I misunderstood, I did it wrong, or I just couldn't get it to work in 26.0. But I'm doing that URL laundry in my app but not using a security-scoped bookmark, because it wouldn't work 26.0. Had I been doing that, then I expect I would have the same problem as you in 26.1. I'm still able to scan the whole drive. I did encounter the ".nofollow" issue in a different feature and resolved it just by rejecting the result from the bookmark decode in favour of my truth data. In this feature, I don't actually need access to the URL, so I'm able to just build the URL from a string. But that's all totally a guess. I still have to think about it some more before I can even reply in that other thread.

But it does interfere. It blocks the operation if _frameLocked == true. I understand this seems pretty simple, but there's no way to know what the impacts of that might be. There are many different setFrame variants. I'm not implying that this is a problem, or in any way related to the message you're asking about. It's just example of the risks of interfering in a really fragile architecture. There are just so many possible causes, it's not reasonable to try to guess. The more you do with Auto Layout, the greater the risk of this kind of message. If you have specific requirement to deploy to 10.13, that's fine. But macOS 13 is really the oldest reasonable deployment target for most apps.

And one more little gotcha. I started all of this from a Login Item. But I've seen references to Login Items being frowned upon by Apple, so I wanted to change that to a Launch Agent. Plus, XPC doesn't work with a Login Item. And this is meant for the Mac App Store, so all of it has to be sandboxed. That meant putting the launch agent into an "app-like wrapper". XPC doesn't work with a sandboxed launch agent either, in spite of it being in an app group. But that's OK. I configure the launch agent from the database and run it on a calendar interval, which is better regardless. But it looks like I got carried away with sandbox restrictions. I have to give my launch agent the "user selected files" capability. Otherwise, it can't talk to the ScopedBookmarkAgent at all, even on Sequoia.

Never use the comments feature. All it does is hide your reply. I see what you mean. I stand corrected.

There's no easy answer here. I wouldn't necessarily ignore the error. There may be one or more UI interactions that you simply haven't tried yet. For example, I recently discovered that if I minimized a window and then restore it, I would get some auto layout errors. I fixed those. But the point is that the window/view controller/view/layout architecture is extremely complicated. These kinds of errors may indicate that you're doing something in the wrong sequence, or doing something else that's invalid in some way. You're running on Xcode 16. It might not work on Xcode 26 or macOS 26. Or maybe macOS 26.1 or 26.2 breaks it. Are you subclassing NSWindow? That is the kind of thing that will get you into trouble. Apple's APIs aren't like Perl. There isn't "more than one way to do it". Rather, on average, there's about 0.92 ways to do it.

I think you filed this as FB20915052; however, this is also a known issue (r.161870449). Not me. There is a bug here, but it's not exactly what you think. The ".nofollow" syntax is a new part of the core system that allows components to construct paths that the lower level system guarantees will not be resolved or followed. This makes it simpler to protect against TOC/TOU attacks by allowing one component of the system to resolve a particular path, then pass that path to another component while guaranteeing that the second component won't inadvertently cause a second resolve. I understand about those kinds of race conditions. I'm not sure why it would be classified as an "attack". And I have no idea what that has to do with URL bookmarks. Unfortunately, the bug here is that parts of Foundation aren't handling this correctly when the path references root. I expect this will be resolved in the next system update; however, it's not clear to me whether that will mean that resolution will return "/" again or that the new "file:///.nofollow/" construct will start working. I don't think we're talking about the same bug here. However, even if we revert to "/", you should be aware that ".nofollow" and ".resolve" paths are not inherently invalid and you should expect to see more of them in the future. They are most definitely invalid. I mean, they do exist. That's not what I'm saying. I'm saying that if I take a given value, and archive it to an opaque type, I expect the unarchive process to return that original value to me. If the unarchive process returns some different value, that's simply wrong. If there are some kinds of security complications, or crazy file system constructs, that's fine. I understand. It's complicated. Then return a failure on the archive or the unarchive. Let me and the user know that the data round-trip has failed. Maybe I ask the user to re-select. Maybe I tell the user that root volumes are invalid and I disallow them in the first place. Otherwise, there's a very real risk that the user opens the app one day and all their data is gone, at least as far as they know. No errors, just no data. As I've said before, this isn't a problem for me. I don't actually need a security-scoped bookmark for this app. I was just trying to write proper code using the proper data structures. I implemented a workaround so I could get the functionality I needed, with code that would automatically use the proper logic once the bug was fixed. I didn't anticipate the unarchive returning valid, but incorrect, data. But I've got it fixed now. I use my workaround to verify the data obtained via the "correct" API. But I really shouldn't have to do that.

QLThumbnailGenerator is for generating thumbnails. It sounds like you are just trying to read whatever icon is there, not generate a new one. Just use one of the NSWorkspace or URL methods to retrieve the icon.

Now that macOS 26.1 has been released, this bug now has different behaviour. It still isn't correct. If anything, it's more wrong than it was before. As of 26.1, when you encode a security-scoped bookmark to "file:///", what you decode will be a bookmark to "file:///.nofollow/". So the decode method now succeeds, but the value is wrong. I actually preferred the behaviour of the original bug. Luckily, due to my limited needs, I was able to easily modify my workaround. Instead of encoding just the URL bookmark, I encode the bookmark, the original URL absolute string, and a secure flag. I just added a check on the decode. If the decoded URL absolute string isn't identical to the encoded absolute string, then reset my url reference to nil, as if it were running on 26.0. I did learn a lot from this experience, and that's always good.