The Rules for Full Disk Access

Hi eskimo,

I DID submit an enhancement request. 🙂

The reason I replied to this dormant thread is that it is the most informational post I've found on "Full Disk Access".

I'm finding that on Catalina, even when I *DO* grant my app Full Disk Access, when I call contentsOfDirectoryAtPath on many folders (such as /Applications/Utilities) the call returns an EMPTY array and a nil error. Even though there ARE of course applictations in that folder.

Further, if I copy, say, a text file into the Utilities folder, then contentsOfDirectoryAtPath returns that file in its result but still no applications!

What gives? Why can my app not "see" ALL contents of any given folder when it has been granted Full Disk Access?

You may be right John, but what a boring world it'll be (for me)... I've always loved writing utilities that "extend" the OS features... if each app is walled off then there is no such opportunity to be "a part of the OS".... I can see the writing on the wall though... looks like my apps will have be sunsetted and my fun curtailed...

That is because you shouldn't consider the path /Applications to be an API. There are, by default, no files in /Applications/Utilities.

This is not a security issue (well, it is, but that's a long story). This is a side effect of how system files have been re-arranged in Catalina.

Why do you want to access that directory anyway? You shouldn't be copying text files there. I assume that was just a sanity check.

The files that you might see in the Applications folder in the Finder now reside, on disk, in multiple places. System files are in /System/Applications. 3rd party files are in /System/Volumes/Data/Applications. But, in most cases, your software has no business being in either. The few case where you might have a legitimate need to access /Applications, you can do so using the /Applications firmlink which will return the contents of /System/Volumes/Data/Applications. And don't forget about ~/Applications. These files aren't merged in the Finder, but they do show up in LaunchPad.

Does all this make sense? If so, good! That makes one person. 🙂

I DID submit an enhancement request.

Cool. What was the bug number?

What gives?

As john daniel explained, this is because of the read-only system volume change in 10.15. WWDC 2019 Session 710 What’s New in Apple File Systems has a bunch of background on this.

Finally, if you want to find all of these directories, it’s best not to hard code the paths, but instead using

NSFileManager

. For example, this:

let userApps = try! FileManager.default.url(for: .applicationDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
print(userApps)
let localApps = try! FileManager.default.url(for: .applicationDirectory, in: .localDomainMask, appropriateFor: nil, create: false)
print(localApps)
let systemApps = try! FileManager.default.url(for: .applicationDirectory, in: .systemDomainMask, appropriateFor: nil, create: false)
print(systemApps)

prints this on 10.14.6:

file:///Users/quinn/Applications/
file:///Applications/
file:///Applications/

and this on 10.15:

file:///Users/quinn/Applications/
file:///Applications/
file:///System/Applications/

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The forum scrambled your output.

Indeed it did. Thanks for pointing that out.

Let’s try that again. Here’s my test code:

let userApps = try! FileManager.default.url(for: .applicationDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
print(userApps.path)
let localApps = try! FileManager.default.url(for: .applicationDirectory, in: .localDomainMask, appropriateFor: nil, create: false)
print(localApps.path)
let systemApps = try! FileManager.default.url(for: .applicationDirectory, in: .systemDomainMask, appropriateFor: nil, create: false)
print(systemApps.path)

It now prints paths, not URLs (-: And here’s 10.14.6:

/Users/quinn/Applications
/Applications
/Applications

And here’s 10.15:

/Users/quinn/Applications
/Applications
/System/Applications

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Big Sur 11.4 has been released, and I've got an issue with one of my apps. This app includes an Helper Tool (a bundle), that is embedded in the LoginItems subfolder. This helper tool is launched thanks to the SMLoginItemSetEnabled API.

Before updating to 11.4, if user granted Full Disk Access to the main app, the Helper Tool got Full Disk Access too, as stated by eskimo.

But now, it's not working anymore. The Helper Tool does not inherit from the main app, either the Full Disk Access but also other authorisations like Automation for Finder.

Did someone find a solution to this?