Scanning Macintosh HD produces single .nofollow file since update to macOS 26.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.

Thanks for your input. I had a look at your link but got lost quite quickly, though I may get back to it if I get really desperate.

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.

I originally wrote that when scanning a folder selected in an open panel it doesn't resolve any bookmark, but looking at the code again it turns out I was already doing that "URL laundry".

What's even more interesting, I tried skipping the laundry (which would resolve the bookmark to a URL whose path property is /.nofollow) and when scanning the URL returned from the open panel directly (whose path property is /), the issue doesn't happen!

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?

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.

To be clear, you mean the root volume* ("/") and not some other, secondary, volume?

*Our default name for the boot volume is "Macintosh HD", but that's not actually required by any part of the system.

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?

My post here breaks this down in more detail, but the summary of the situation is that:

1. The per-kernel/lower-level system, the paths "/.nofollow/" and "/" both refer to exactly the same directory, namely "/".

2. A bug in CoreFoundation is "stripping" the last "/" from "/.nofollow/", unintentionally changing the meaning to the "stub" directory "/.nofollow".

3. Security-scoped bookmark resolution is broken in 26.1 due to these issues.

4. Issue #3 is fixed in 26.1, though the larger issue (#2) has not yet been fixed.

The key point I want to emphasize here is that the problem is specifically with how Foundation is handling the "/.nofollow/" prefix, NOT the fact that we're returning "/.nofollow/" paths.

What's even more interesting, I tried skipping the laundry (which would resolve the bookmark to a URL whose path property is /.nofollow) and when scanning the URL returned from the open panel directly (whose path property is /), the issue doesn't happen!

Yes, though this is somewhat accidental and tied to the details of exactly how URLs are passed into your app from the agent that actually presents the panel interface.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware