macOS 12.3 introduces serious, fundamental AppleScript bug

[ShaneStanley]

@learnedapplescript

macOS Monterey 12.3 breaks the ‘open’ command with Finder

I gather this has been fixed in 12.3.1.

[peavine]

I upgraded to 12.3.1 and, when using the Finder to open a PDF, I now get intermittent error messages like:

The file “AppleScript Objective C.pdf” couldn’t be opened because you don’t have permission to view it.

It doesn’t seem to matter if I use alias or file specifiers, and the PDF document itself doesn’t appear to make a difference. This also happens with text files:

The document “New Text File 1.txt” could not be opened. You don’t have permission.

It makes no difference if the script is run from Script Debugger, Script Editor, or as an app on the desktop. I never had this issue before 12.3.1.

Edit. April 2, 2022.
I mentioned above that this issue was intermittant, and a controlling factor seems to be whether an attempt was made to open the file recently. The first attempt to open the file returns the error message; a second attempt often successfully opens the file. I modified all of my scripts affected by this bug to use ASObjC to open files (as suggested by Shane), everything works fine.

[laughingtiger]

tell application "Finder"
	set theFiles to every file of (path to documents folder) whose name extension is "pdf"
	repeat with thisFile in theFiles
		set thisPOSIXfile to POSIX path of (thisFile as alias)
		reveal thisFile
		--do shell script "open " & quoted form of thisPOSIXfile
		open thisFile
	end repeat
end tell

I can confirm that the problem still seems to exists after the 12.3.1 update on my machine (Mac mini 2018)
Running the above test script I have discovered…
If the file has been previously opened recently, either manually by double clicking on it etc or by using the shell script Open command, then the Finder script will open it. I assume that opening the file in this way sets some kind of flag.
I have noticed that running the above script without the shell script open command, even though the Finder will not open files not recently opened, the script does however set the ‘Last Opened’ value in the Finder window listing to the time at which the Finder open command failed.
I haven’t yet tried testing to see if there is some kind of ‘timeout’ associated with whatever flag is set after a file has been opened or if that flag survives a restart of the Finder or even host machine.

I wouldn’t be surprised if this has something to do with the files ‘com.apple.macl’ extended attribute

see: https://eclecticlight.co/2020/01/07/diagnosing-privacy-protection-problems-in-catalina/

"The xattr which is associated with Catalina’s protected folders is com.apple.macl, which is usually (but not always) protected by SIP, so you can’t remove it from the document or folder, which is a real pain. This xattr contains one or more UUIDs which are associated (somewhere) with (non-sandboxed) apps. Its purpose appears to be to maintain document access when files are moved between protected and unprotected folders: it seems to act as a whitelist which ensures that, no matter where that document goes, approved apps will continue to be able to access it.

It is also a hallmark of the per-file privacy protection system at work. Abandon hope all you who enter here."

This is madness.

[seanmurp (Sean Murphy)]

I just installed 12.3.1 and have not seen any issues with a Finder Open command. Tried several different file types and several different files that had not been accessed in ages.

[learnedapplescript]

@ShaneStanley

I gather this has been fixed in 12.3.1.

Thanks! Seems to have fixed one of the main problems that 12.3 was causing my application as well. Great news.

@laughingtiger

I can confirm that the problem still seems to exists after the 12.3.1 update on my machine (Mac mini 2018)

Sorry to hear that folks are still experiencing issues with permissions. This is odd.

@peavine

intermittent error messages

In particular, this worries me. Guess I have to test extensively before reverting to any solution that was previously broken.

[learnedapplescript]

As others have stated, here and elsewhere, unfortunately this issue hasn’t been fully fixed in macOS 12.3.1. Linking these posts to continue the discussion here as well.

Should I be worried about Monterey?

This is absolutely right. I thought this had been fixed, but I hadn’t fully tested our application, and when it downloads a ZIP for the first time and then tries to extract it, the script fails because of the same permissions bug. This is because the script just “opened” the ZIP file with Finder, which would then direct Archive Utility to actually do it. Unfortunately, using AppleScript to tell Archive Utility to “open” the file results in Archive Utility displaying the same error instead of F…

Should I be worried about Monterey?

There is a known problem introduced in 12.3, partly fixed in 12.3.1: There still appears to be a problem when opening a file via Finder’s open command. e.g. Take a screenshot, then tell Finder to open it: tell app "Finder" to open file "Screenshot 2022-04-15 at 09.44.59.png" of desktop If the file hasn’t previously been opened by other means, e.g. by double-clicking on it or by telling another app to open it (e.g. tell app "Preview" to open …), then Finder throws up a permissions error an…

[learnedapplescript]

Would also appreciate any help with restoring my script’s ability to unzip a ZIP archive.

Using the “tell Finder to open” command on the ZIP file no longer works, nor “tell Archive Utility to open,” and neither does the “unzip” shell command (all return errors that describe a permissions issue).

Should I be worried about Monterey?

Just tried unzipping with the “unzip” shell command, but that returns a different error message which essentially describes the same thing: checkdir error: cannot create [folder/file name of whatever is in the ZIP] Read-only file system unable to process [same folder/file name]" It goes on and on, listing an identical error for every file and folder within. Either this is a ridiculously systemic bug or intentional. This makes me think it’s intentional—the extra detail in the message from…

[peavine]

@learnedapplescript

Would also appreciate any help with restoring my script’s ability to unzip a ZIP archive.

Using the “tell Finder to open” command on the ZIP file no longer works, nor “tell Archive Utility to open,” and neither does the “unzip” shell command (all return errors that describe a permissions issue).

As a temporary workaround have you tried using ASObjC as suggested by Shane?

use framework "AppKit"
use framework "Foundation"
use scripting additions

set zipFile to POSIX path of (choose file)
set theWorkSpace to current application's NSWorkspace's sharedWorkspace()
set theURL to current application's |NSURL|'s fileURLWithPath:zipFile
theWorkSpace's openURL:theURL

EDIT: April 16, 2022
I just noticed that learnedapplescript commented in an earlier post that ASObjC was not an option in his case. So, no help here.

[learnedapplescript]

@peavine

I just noticed that learnedapplescript commented in an earlier post that ASObjC was not an option in his case. So, no help here.

Yeah, unfortunately it isn’t feasible at the moment. I appreciate your help nonetheless.

But maybe I could put this logic in a handler within a separate ASObjC script file, called by the main script?

I have lots of scripts bundled that the main script of the applet calls, but all of them are vanilla AppleScript. Can the vanilla AS script call a separate ASObjC script without making the main script ASObjC? I’m assuming, if this is possible, that it would have to “run” the script, not “load” it.

If so, I’ll have to try that, see if it’s workable, and report back. (Will be annoying if that, too, gets impacted by a future security update, or due to this permissions issue, not work right now either).

[ShaneStanley]

@learnedapplescript

Can the vanilla AS script call a separate ASObjC script without making the main script ASObjC?

Certainly.

@learnedapplescript

I’m assuming, if this is possible, that it would have to “run” the script, not “load” it.

Put it in a script library, and include it in your script via a use script statement.

[peavine]

@learnedapplescript

But maybe I could put this logic in a handler within a separate ASObjC script file, called by the main script?

I have lots of scripts bundled that the main script of the applet calls, but all of them are vanilla AppleScript. Can the vanilla AS script call a separate ASObjC script without making the main script ASObjC? I’m assuming, if this is possible, that it would have to “run” the script, not “load” it.

I happened to read an article by Shane on a related matter, and it occurred to me that there’s another workaround to consider. The following script works without but not with the use framework statements:

use framework "AppKit"
use framework "Foundation"
use scripting additions

set theFile to (path to home folder as text) & "Test.txt"
set theText to (read file theFile) --> Can’t make current application into type file.

However, if the script needs ASObjC to open a file, this can be done within a script object:

set theFile to (path to home folder as text) & "Test.txt"
set theText to (read file theFile)
openFile(POSIX path of theFile)

on openFile(theFile) -- theFile must have POSIX path
	script theScript
		use framework "AppKit"
		use framework "Foundation"
		on openFile(theFile)
			set theWorkSpace to current application's NSWorkspace's sharedWorkspace()
			set theFile to current application's |NSURL|'s fileURLWithPath:theFile
			theWorkSpace's openURL:theFile
		end openFile
	end script
	theScript's openFile(theFile)
end openFile

[learnedapplescript]

Interesting. Thanks so much to both of you! I’ll have to try this, as well as another solution mentioned in the other thread, as soon as I’m able, and see which one works, or works best.

[peavine]

I just installed Monterey 12.4 and I still receive the same error when attempting to open a file with Finder:

The document “New Text File 1.txt” could not be opened. You don’t have permission.

[kerflooey (M)]

Hi. I’m considering updating to 12.6 Monterey soon (on Intel Macs). Do you know if this Open File problem been has been fixed? Thanks!

[peavine]

I’m running Monterey 12.6 on a 2018 Mac mini and it hasn’t been fixed for me.

set theFile to (choose file)
tell application "Finder" to open theFile 
--> The document “New Text File 1.txt” could not be opened. You don’t have permission.

[kerflooey (M)]

@peavine

set theFile to (choose file)
tell application "Finder" to open theFile

Wow, thanks. Your code doesn’t work on my Catalina either without the word “file” before theFile, or set theFile to «class furl» first.

[peavine]

@kerflooey

Wow, thanks. Your code doesn’t work on my Catalina either without the word “file” before theFile, or set theFile to «class furl» first.

Nothing seems to work for me.

set theFile to (choose file)
tell application "Finder" to open file theFile
--> The document “New Text File 1.txt” could not be opened. You don’t have permission.

set theFile to (choose file) as text
tell application "Finder" to open file theFile
--> The document “New Text File 2.txt” could not be opened. You don’t have permission.

set theFile to (choose file) as «class furl»
tell application "Finder" to open theFile
--> The document New Text File 3.txt” could not be opened. You don’t have permission.

set theFile to (choose file)
tell application "Finder" to open theFile as «class furl»
--> The document “New Text File 4.txt” could not be opened. You don’t have permission.

[Fredrik71 (Fredrik Gustafsson)]

Make sure to open the file first with Finder, if you get permission warning.
It does work for me to tell Finder to open files. Monterey 12.6.1

[ionah (Jonas Whale)]

Here is a possible workaround not using AppleScriptObjC under Monterey 12.6.1:

-- open the file using its url property (must be coeced to alias)
tell application "Finder" to set theFile to make new file at (path to desktop)
tell application "Finder" to set theURL to URL of (theFile as alias)
open location theURL

-- check out if the file can be opened afterwards
delay 2
tell application "TextEdit" to close document 1 saving no
tell application "Finder" to open theFile

Let me know if it works for you.

[learnedapplescript]

It was partially fixed in 12.3.1, but I can’t recall the details—enough for my particular use case to function again. I’m on Ventura now.