{"id":27490,"date":"2019-12-03T16:55:59","date_gmt":"2019-12-03T21:55:59","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=27490"},"modified":"2020-07-03T16:47:04","modified_gmt":"2020-07-03T20:47:04","slug":"reading-the-resource-fork-too-often","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/12\/03\/reading-the-resource-fork-too-often\/","title":{"rendered":"Reading the Resource Fork Too Often"},"content":{"rendered":"

Mark Alldritt<\/a>:<\/p>\n

\n

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<\/code>) or -43 (fnfErr<\/code>) 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.<\/p>\n

[…]<\/p>\n

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).<\/p>\n<\/blockquote>\n\n

You’d think that old deprecated stuff like resource forks would just keep working in its frozen state. But both Mojave and Catalina introduced resource bugs that have hit my apps. There are more modern replacements for many uses of the resource fork, but they don’t always work. And, as with the AppleScript example, sometimes the resource fork is unavoidable, and the problems even hit Apple’s own apps.<\/p>\n\n

Previously:<\/p>\n