Creating an URL bookmark in macOS 26.1 of a Windows NTFS fileshare returns a bookmark with access to the local drive

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.

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.

@Etresoft No, the decoded URL is not the same as the encoded URL. That's the whole point of my post.

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.

Since macOS 26.1, creating bookmark data based on a NSOpenPanel URL does not return the expected bookmark data when the selected source concerns a Windows NTFS fileshare.

What are you accessing here? Is this an SMB share of an NTFS volume or a NTFS volume you've directly mounted? If it's directly mounted, is it mounted through our read-only driver or a 3rd party file system driver? If this is an SMB share, what's the sharing device?

In essence, the following code line with 'url' based on an URL from a NSOpenPanel after selecting the root of a Windows NTFS share creates an incorrect bookmark in macOS 26.1:

What is the starting URL and what do you get when you resolve the bookmark? Is there any intermediate activity (like an unmount/remount) or does this happen when you immediately resolve the bookmark?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@DTS Engineer It concerns SMB shares of NTFS volumes hosted on Windows PCs.

The starting URL could for example be file:///Volumes/Videos/, but the resolved URL is file:///.

This happens immediately after resolving the bookmark data, even if that data has been created in the same code context. To be clear, only in macOS 26.1. In older macOS versions the starting URL and resolved URL are identical.

FB20917638 contains instructions and a sample project to reproduce the issue.