I am trying to open external/mounted storage in Finder. I simply just want to show the root directory. I have tried multiple things, none worked.
NSWorkspace.shared.open()
Does work when opening the user's disk (e.g. Macintosh HD), but when comes to any of the external storages a warning appears: "The application "ABC" does not have permission to open "Folder Name".
Now, the app ha been granted all permissions in the preferences (Full Disk Access + Files and Folders). Furthermore, I don't even need or care of accessing this directory from within my app. I want the Finder to open it.
I am using com.apple.security.files.user-selected.read-only
and testing on MacOS: 14.6.1
I am trying to open external/mounted storage in Finder. I simply just want to show the root directory. I have tried multiple things, none worked.
First off, please file a bug on this, specifically asking for an API that will ask the Finder to open a new window that shows the contents of a folder/directory without taking any other action, then post the feedback number back here.
We have an API that is ALMOST what you want, but we really need to expand it some to cover all cases.
Moving to this option:
Though deprecated, the following is working for me in 14.6.1 (23G93):
NSWorkspace.shared.openFile("/Applications", withApplication: "Finder")
and (using a usb drive)
NSWorkspace.shared.openFile("/Volumes/NO NAME", withApplication: "Finder")
This code does NOT work in the general case, nor is it necessary to use the deprecated API. The modern equivalent here is "open(_:withApplicationAt...)" and if you compare the behavior of "openFile...", you'll find they behave the same. More specifically, unless you app has it's own access right to the directory:
-
Certain directories work fine, with
"/Applications/"
being one example. Those are directories where the app sandbox has an implicit extension to allow apps access to those directories. Similarly, it should work if you app has valid access to the directory through some kind of security scoped resource. -
Most directories will fail.
-
A few directories may SOMETIMES work, which is probably why this worked:
NSWorkspace.shared.openFile("/Volumes/NO NAME", withApplication: "Finder")
Volumes are the complicated edge case here as apps have an extension for "/Volumes/",
but they don't have an extension for individual volumes. I'd need to play with the case above to be sure, but my guess is that this particular case was probably an ExFAT disk image, which ended up creating an extension that would otherwise not have existed.
Regardless, this isn't something you can rely on.
In any case, the correct API for this is actually "NSWorkspace.activateFileViewerSelecting()". That API was designed to be as "sandbox safe" as possible and, in fact, does not require your app to have ANY access or entitlement to the target file. You can actually pass in an arbitrary path and the Finder will happily show it, even if your app doesn't have any file system access at all.
Internally, it uses the same basic code path as the "Show In Finder" service, which basically just passes a string to the Finder which the Finder then presents. Unfortunately, that's where the limitation comes from. It selects an object "inside" it's parent folder, but it doesn't provide any way to simply open a directory "directly". That means you can use it to:
- Open
"/Volumes/"
and select a particular Volume
OR
- Open a volume and select an object inside it, assuming you happen to know the name of an object inside the volume.
...but you CAN'T use it to open and show a volume contents or the contents of an empty directory.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware