macOS Monterey 12.3 breaks the ‘open’ command with Finder. It has broken gigantic AppleScripts I’ve used for years. ‘Activate’ reportedly is a solution for launching apps, but not work when you’re trying to launch a specific file. This is terrible.
I assume this is related somehow to the security updates that 12.3 brings (which specifically call out AppleScript). I hope we can file radars about this that are successful.
I’m trying to rewrite my multi-thousand line program that a team uses, but it’s been hard to get it to work like before so far (multiple strange errors including -1703).
use framework "AppKit"
use framework "Foundation"
use scripting additions
set rtFile to ((path to desktop as text) & "richtext.rtf")
openFile(POSIX path of rtFile)
on openFile(thePath) -- POSIX path
set ws to current application's NSWorkspace's sharedWorkspace()
set theURL to current application's |NSURL|'s fileURLWithPath:thePath
ws's openURL:theURL
end openFile
Unfortunately, in my main applet that’s most important to me, you were the one who showed me last year how ASObjC makes file paths harder to work with, or more unreliable—or something like that.
I don’t remember the specifics exactly, but I know that at that time I had made up an alternate build using ASObjC, and decided to opt for PrefsStorageLib instead, since I ran into problems that couldn’t be circumvented because of that.
Thank you! As mentioned, last year, in order to implement persistent properties in my applet (replacing the native AppleScript properties) I had to choose between your ASObjC code that did so, and PrefsStorageLib.
I ended up going with vanilla AS + PrefsStorageLib back then.
Can I combine both ASObjC and PSL now? I don’t want to rewrite the property implementation a second time just to use ASObjC code instead of calling PSL, but I would maybe consider implementing ASObjC for the file reference problem.
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.
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
"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."
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.
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.
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.
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).
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
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.