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.

No, the decoded URL is not the same as the encoded URL. That's the whole point of my post. So how is it different? I'm going to update my thread complaining about security scoped bookmarks, but all I can so is complain. That won't fix anything. In my limited case, it doesn't actually matter. I just updated my code to compare the original URL with the decoded one and I reject any value that's different. That gets me back to the old 26.0 behaviour. That's still broken, but broken in a better way. In my workaround, I define a URLBookmark class that encode/decodes the URL absolute string, the bookmark, and a secure flag. Originally, if decoding a security scoped bookmark failed, I would fall back to a standard bookmark, and then fall back to just the absolute string. But I don't actually need a security scoped bookmark. I'm just getting certain volume attributes that should (fingers crossed) always be accessible. I did have plans for using document-scoped bookmarks in the future, but those plans are fully dashed at this point.

You can get this information from IOKit. But I'm not sure what notarization has to do with anything. You can even get this information from the sandbox.

Never use the "comments" feature here in the forums. They don't trigger notifications and people don't notice them. This was an annoying bug for me so I wanted to double-check and close the loop. Otherwise, I might have forgotten about it and never seen your comment. But my bug does seem to be fixed. I actually got thrown off when you said "NTFS". I was thinking about the NTFS driver. You're actually talking about SMB file shares. I just tested that and it seems to work fine for me. However, I have a special use case. I don't actually need to look at the data. But curiously, the bookmark I restore is NOT the same one I saved. When I save a bookmark to the root filesystem of the startup volume, the url I decode is file:///.nofollow/. So dig into your code and see if the url you are decoding from the bookmark is actually the same url you encoded. I'm not seeing this behaviour on a network volume, but I'm using a Mac as a server.

Creating bookmarks to the root directory of a volume was broken in earlier versions of 26. It looks like a change was made and that change broke NTFS. Good thing I haven't released yet. I need to double check. My workaround assumed that creating the bookmark would fail. I didn't anticipate success with invalid data. I don't know if my workaround would work for you. I have a special case where I don't actually need to access the data. I just want to know the URL. I can get the data I need without a security scoped bookmark. And it sounds like I need to re-do it anyway.

Looks like Full Disk Access is broken in 26.1. It only works with full-fledged apps, not command line tools. The error log seems to suggest that it wants a bundleID, which is something that typically only apps have. It is possible to shove a bundleID into a command-line tool. And sshd-keygen-wrapper has that. But I guess that hack isn't checked. Someone discovered this on another forum and I tried it with my own tool. I couldn't get it to work either.