When trying to export a run-only version of an applet from Script Debugger 7 I’m getting the following error: “file is locked (fLckdErr:-45)”.
I’m running Big Sur on Apple Silicon.
It only seems to happen when I use certain script libraries (haven’t narrowed it down to exactly which ones) and tick the Make bundled scripts & libraries run-only checkbox. One of my applets which uses just one library (Shane’s prefs storage lib) can export a run-only version fine with the Make bundled scripts & libraries run-only checkbox ticked, but another applet which uses a bunch of libraries is the one that is throwing the error.
I thought I effectively needed to (or it was best to) make included libraries run only so that I could notarise for distribution. Is that right and why am I getting the file is locked error?
The error happens whether I try to export manually or via a script. It happens regardless of whether or not I codesign the applet. It happens regardless of whether I export it to Dropbox, iCloud Drive or my local disk. Script Debugger has full disk access in System Prefs > Security & Privacy and I have tried toggling it off and on again to work around what I hear is a bug that affects at least some apps.
The script/applet being exported is a standard Apple applet set to stay open and not ask to run on launch and set to include used libraries when exporting and to code sign on export only.
If anyone can offer some help on why this might be happening or how to get around it, it would be greatly appreciated.
Yes, I checked and Script Debugger had and has full disk access. I tried toggling it off and then on again as apparently that can sometimes fix permission related issues. It seemingly had no effect.
It doesn’t seem like it’s related to the file system as I can export the same run-only applet to the exact same location if I uncheck the make script libraries run-only tick checkbox.
Unfortunately it’s not that simple. Converting scripts to run-only involves reading and writing files, and it’s too much of that that seems to be able to trigger a response from system security.
It turns out the libraries are a red herring. The issue is a bug where Script Debugger is trying to make scripts outside those two folders run-only, including those in your Helper Apps folder. These apps have their main.scpt files set to be read-only as part of code-signing, so they can’t be modified, and hence the error.
If you’re planning to notarize with SD Notary, don’t codesign files. SD Notary has to re-sign it differently anyway, so it’s at best wasted effort. The same goes for your helper apps. (In fact, the signing done by Script Debugger 7 is largely pointless these days, because it no longer satisfies Gatekeeper.)
So the workaround is to remove the helper apps, export without signing, then add the helper apps to the bundle manually, before notarizing.
You could also try exporting from Script Debugger 8, to see how that goes. In that case, you will end up with a universal binary.
Amazing! Thanks so much for tracking that down for me, Shane!
Why do you think this issue was only now occurring? I’ve been exporting this applet run-only with the helper apps for a while now without this issue. The only thing that seems to have changed from what I can tell is that this is the first time I’ve tried to do it on Big Sur/Apple Silicon. Previously it had been on Mojave.
Okay, good to know. Thank you.
Could an alternative be to add unsigned versions of the helper apps to the bundle so that each time I want to export I can just export run-only without signing and then notarise straight away? If so, would it matter whether the helper apps are saved/exported as run-only?
I’m very excited to try Script Debugger 8, but I was a little scared by the advice in Mark’s post not to use production scripts with SD 8. Can I have both SD 7 and SD 8 installed at the same time without causing any issues?