ALERT: "Cannot save document" error on Catalina systems

IMPORTANT NOTE FOR CATALINA USERS

The Problem

We have identified a problem where Script Debugger becomes unable to save document changes to compiled script (.scpt) and text (.applescript) AppleScript files on macOS Catalina systems.

This problem happens after a document has been opened in Script Debugger and changes have been saved a number of times. If the saves are done in fairly quick succession, Script Debugger will begin reporting that it cannot save document changes. In some instances, errors -54 (permErr) or -43 (fnfErr) are reported. Additionally, once this situation arises and you close the document, it is no longer possible to open the effected document in Script Debugger.

Workarounds

UPDATE: We have found that granting Script Debugger Full Disk Access using the Security & Privacy pane in System Preferences resolves this issue.

We have found that if one simply waits, the problem clears itself and you can once again save changes and open documents.

Another solution is to save your document as a compiled script bundle (.scptd filename extension) as this file format stores its meta-data in a way that does not trigger this problem.

We have implemented a partial workaround for this issue in the Script Debugger 7.0.11 maintenance release. This change should avoid the problem where document changes cannot be saved, though meta-data stored in the document by other applications such as the Script Editor may be lost. However, this change does not address the problem where documents cannot be opened.

Background

This situation can be reproduced outside Script Debugger which leads us to believe it is a macOS Catalina problem rather than a Script Debugger problem.

At a technical level, the problem is triggered when applications attempt to read the resource fork of a document repeatedly within a given period of time. This behaviour by an application seems to trigger a security mechanism within Catalina that prevents further access to the document’s resource fork (the resource fork is used to retain meta-data in text and compiled AppleScript documents).

To reproduce the problem you can follow these steps:

  1. Create a simple document using the Script Editor
  2. Save the document as a compiled script file (.scpt filename extension)
  3. Make some changes, and save again, repeat a couple of times
  4. Close the document
  5. Use DeRez from the command line to view the file’s resource fork and you’ll get a permErr (-54):
mark$ DeRez /Users/shane/Desktop/TestScript.scpt 
### DeRez - permErr (-54) during open of resource file "/Users/shane/Desktop/TestScript.scpt".

We are working with Apple to resolve this issue and will update Script Debugger again when a solution to the problem becomes available. However, it may turn out that macOS Catalina will need to be updated to resolve the issue in which case we’ll have to wait for Apple to release an update.

2 Likes

A follow-up: turning on Full Disk Access for Script Debugger in System Preferences works around this issue. As of version 7.0.11, you will be prompted to enable this at launch, if you have not already done so.

Thanks for the followup. I saw that was an addition in 7.0.11

Is there a way to trigger the same alert using AppleScript? I am assuming I could try to perform an action that would fail when Full Disk Access is off, and I could put up a dialog like you are doing with Script Debugger? What is the simplest “test” to use to see if Full Disk Access is on or off? Can you actually find out from “System Preferences” itself? I think I know how to pull up the System Preferences pane, but not sure of the most universal way to trigger Full Disk Access being an issue.

There’s no official test. Basically, you need to call the NSFileManager method isReadableFileAtPath: for a protected file. There’s code here:


that provides a couple of suggested paths in ~/Library/Safari, depending on OS version, and Script Debugger is using those too.

Thanks, the posted solution which is to grant Full Disc Access helped me to resolve exact same issue on Mojave with Apple’s stock Script Editor. The problem has been around since 10.7 and resurfaces periodically which is a terrible shame.
The omission on part of Apple is that Script Editor doesn’t ask for full access.