When creating or editing an Applescript with Script Debugger 8.0.4 I am unable to save a compiled Applescript (.scpt) file to my Google Drive. I am able to save compiled script bundles (.scptd) or compiled applications. Thought it was an access issue. SD has full disk access. I can save anywhere else on my Mac, just not .scpt on Google Drive. An interesting twist, Apple’s built in Script Editor has no issue saving .scpt files to Google Drive.
Any ideas?
Just so that everyone knows: The latest Google Drive implementation mounts the drive via a local SMB server, i.e. it behaves like a network drive.
Thus it’s probable that either SD or macOS has a problem with .scpt files on network (SMB) shares.
Unfortunately the error alert alone does not give any indication of the cause of the failure. Please check your Console log to see if any additional diagnostic information is recorded when you attempt to save your document. You can filter the Console log by application to isolate information logged by Script Debugger.
Can you also try saving as a .applescript file?
yes, it works without issue saving as text (.applescript). The issue only shows up with saving compiled applescript (.scpt). The issue is consistent with “Save”, “Save As”, “Save a Copy” and only when trying to save as a compile applescript (.scpt).
I opened a “BJs Coupons.scpt” file from Google Drive, made a simple edit and tried to save on Google Drive as the same filename. Here’s the log output with a few errors showing up. It’s showing an invalid filed descriptor argument and and extended attributes as invalid. Any ideas on what to try?
default 05:41:27.895524-0400 Script Debugger could not set attributes com.apple.ResourceFork on destination file descriptor: Invalid argument
default 05:41:27.897576-0400 Script Debugger error processing extended attributes: Invalid argument
default 05:41:30.689002-0400 Script Debugger 0x1170814c0 - [PID=0] WebProcessCache::setApplicationIsActive: (isActive=0)
default 05:41:30.689117-0400 Script Debugger 0x117081600 - [PID=0] WebProcessCache::setApplicationIsActive: (isActive=0)
default 05:41:35.559056-0400 Script Debugger LSExceptions shared instance invalidated for timeout.
default 05:42:42.706844-0400 Script Debugger Read options: 80000001 – URL: – purposeID: 18213765-EAB0-4B68-8BE4-845066F888FE – claimID: 4D9F3FE1-427C-475B-B304-4C07229E7A76
default 05:42:42.706881-0400 Script Debugger Write options: 0 – URL: – purposeID: 18213765-EAB0-4B68-8BE4-845066F888FE – claimID: 4D9F3FE1-427C-475B-B304-4C07229E7A76
default 05:42:42.713057-0400 Script Debugger Claim 4D9F3FE1-427C-475B-B304-4C07229E7A76 granted in client
default 05:42:42.713077-0400 Script Debugger Claim 4D9F3FE1-427C-475B-B304-4C07229E7A76 invoked in client
error 05:42:42.714102-0400 Script Debugger _dirhelper_relative_internal: error for path : [2: No such file or directory]
default 05:42:42.714272-0400 Script Debugger Write options: 0 – URL: – purposeID: D8093841-4303-40FF-8ECA-9EABA10D2F61 – claimID: A0072D0C-7CE5-430B-B5A0-6B7C48DEB858
default 05:42:42.716613-0400 Script Debugger Claim A0072D0C-7CE5-430B-B5A0-6B7C48DEB858 granted in client
default 05:42:42.716631-0400 Script Debugger Claim A0072D0C-7CE5-430B-B5A0-6B7C48DEB858 invoked in client
What version of macOS are you running?
It sounds very similar to the underlying issue that happens when Full Disk Access is off (I note you have it on).
I’m on Monterey 12.3.1
I’m having a lot of issues saving to an iCloud folder as well. Wonder if its related. also running 12.3.1
I cannot reproduce the problem you are experiencing here on my M1 Monterey 12.4 system. I installed Google Drive today and have been able to save without incident. I did have to grant access to Google Drive to some sort of helper application, but once that was done, it works as I would expect it to.
I retested saving scripts to iCloud Drive and here again I’m not experiencing problems you are seeing.
When I read through the console log message your posted, I thought at first that Google Drive was simple unable to handle files with resource forks, but that does not seem to be the problem as I can save without any problems.
We have had issues in the base where repeated saves of the same .scpt file can cause macOS’s security system to become involved and signal that a file cannot be saved. Generally, waiting “w while” (we’ve not been able to establish a specific time interval) allows the problem to clear. This is all happening within macOS, and Script Debugger is simply the messenger.
I am stumped. I hate to suggest a system reboot, but some file access issues have been resolved by reboots so you may want to try that. I would ensure that the following settings are in place before rebooting:
If the problem persists following a restart, please collect more Console log output. Hopefully something will appear that helps us identify where the failure is happening.
Mark,
Thanks for the detailed response. Yes, I have done several reboots in this process and have verified the permissions. I unset/reset the permissions numerous times also. I also have the same issue between 2 different Mac systems.
I have however found what causes the issue I’m seeing. It thas to do with “Stream Files” from Google Drive. Once I set it to “Mirror Files” the error disappears and I can save .scpt files. So I do have a workable solution/workaround.
What puzzles me still is why I can save all other file formats from SD8, only the .scpt files are the ones that experienced the error.
Yes, that is a puzzle. The .scpt and .applescript file formats both use Resource Forks and extended attributes to store meta data relating to your script (window size, script description and other view settings). The actual script data is stored in the data fork. I would expect both file types to fail in the same way.
Correction to my former post:
Google Drive only acts as a network volume if you configure it to load files on-demand (Streaming mode), which is the default mode for a fresh install or even an update (I think). If you instead use the “Mirror” option, then it’ll work like Dropbox, i.e. it’ll store its files in a local folder of your choosing. The mirror option is, as Pete has pointed out, the solution to this topic’s issue.
Curiously, though, saving to a regular SMB share (Synology NAS) with SD 8.0.4 in macOS 12.4 shows no issue here. So it seems that GDrive’s SMB server is at fault here.
I don’t think that “mirror mode” is the solution, more a good work around.
As stated in my initial post. Apple Script Editor application will save all file types (.scpt, .scptd, .applescript and .app) to Google drive in either “stream” or “mirror” mode. I only have this issue with SD8 in “stream mode”.
So there has to be more to it.
There is. The problem is that .scpt files are written using the Resource Manager, which is a very old hangover from pre-OS X days, and repeated calls to it in quick succession can trigger a permissions error. Script Editor dodges a lot of permission issues simply because Apple software is treated differently.
Is there anything important that absolutely must be stored in com.apple.ResourceFork, or would it be feasible to transition .scpt files to xattrs at some point like you did with .applescript?
I ask as an interested party, since iCloud Drive also doesn’t play well with com.apple.ResourceFork but handles other xattrs (as discussed in Allow QuickLook Preview to Pass Through iCloud). I imagine that this will continue to be an issue as cloud services become more & more ubiquitous.
We have considered this change several times.
The problem is the script’s description which is stored in the resource fork along with a few other settings. Moving to xattr would sacrifice interoperability with Apple’s Script Editor and any other runtime that presents the script’s description.
We’ve always endeavoured to avoid locking people into Script Debugger specific file formats.
if Apple ever makes the transition from resource fork to xattr for everything we will follow. Even if this happens, we’ll probably have to write both to ensure compatibility with old software.
Thank you for that explanation, it now makes sense to me why the behavior is different.
