Note: When I posted this message in the Files and Folders section, I included a link to the LateNight Software forum, so the message got flagged as spam. Here it is without the link, and in a more suitable forum:
This is a message I posted in the LateNight Software forum (which supports the Script Debugger app) about the new Mac backup system. The problem I describe is likely to occur with other applications than the ones I wrote about (and which I wrote for public distribution). The only way I solved it was by deleting my entire Catalina system and restoring it from a Carbon Copy Cloner backup that I made before using the new Dropbox Mac backup system. There may have been an easier way to fix it, but I didn't find it.
I can't include a link to my original post at LateNightSW, because the forum flags the link as spam, but it should be easy to search, and it may be useful to see if there are any followups.
After transferring my Catalina system to a replacement SSD, Dropbox offered to setup a new system that backs up my Desktop, Documents, and Downloads folder. Apparently this system is in beta, and is offered only some setups, and my new disk triggered the offer when Dropbox recognized that I was using a new disk and required me to log in and set up Dropbox on the disk.
Thinking this backup might be a good idea, and not reading the fine print, I clicked Yes, and then a lot of my scripts stopped working. If I ran a script from the desktop, the problem occurred with the first line that ran a shell script that (for example) copied a file stored inside the applet; that line produced an “Unexpected token near position 0” error (or something similar; I’m writing from memory).
It turned out that Dropbox had moved all my Desktop files into the Dropbox folder, leaving symlinks behind, and that any script that I ran that referred to the POSIX path of the applet itself now used a path that had parentheses in it - and the first parenthesis was the “unexpected token.”
After I got rid of the Dropbox backup system and moved the backed-up files back to my desktop, most of them worked, but one kept giving a “not authorized to send Apple events to the Finder” error, no matter how many permissions I gave it. Possibly I could have tracked down every hidden cached reference to that script, but it wasn’t worth the effort, so I fixed the problem by drastic means: I removed the whole Catalina system from my new disk, and restored it again from a Carbon Copy Cloner backup of the old disk. I had to reinstall Catalina to make it work, but everything in my user folders was intact and functional.
Needless to say, if Dropbox offers to back up your Mac desktop, documents, and downloads folder, don’t do it. But the more troubling question is this. Because other people will turn this feature on, and break some scripts that are run from the backed-up folder and use Unix paths to themselves, how can a script test for this and either work around the issue or warn the user to move the script to some other location?
Also, though I don’t want to experiment with this again, if the persistent problem I had with “Not authorized to send Apple events to the Finder” is something that can’t be fixed in any user-friendly way (and possibly only by restoring a whole system from a backup), would a test like this be enough to prevent it from happening? (I know I’m asking only for speculation here.)
Again, this won’t affect scripts that don’t use POSIX paths to themselves, and won’t affect all such scripts, but it seems like a very serious potential problem.
Well, I figured out what's going wrong, but this is based partly on memory. With the new system, Dropbox moves desktop, etc., files to a folder in Dropbox that has parentheses in its name. When I run my own AppleScript applications from the desktop under the new system, I get errors that are LIKE this (made by experimenting with folders that have parentheses in them):
2020-05-31 09:20:20.767 defaults[29618:6975445] Could not parse: /Users/edward/Desktop/My (Folder) Name/vDosWP-CX copy.app/Contents/Resources/vDos.app/Contents/Resources/drive_c/Program Files/vDos/. Try single-quoting it
When I tried rewriting my own application by single-quoting the path, I got this error, which is almost identical to the one I got with the Dropbox system:
sh: -c: line 0: syntax error near unexpected token (' sh: -c: line 0: defaults write org.wpdos.vdoswp vDosFolder ‘’/Users/edward/Desktop/My (Folder) Name/vDosWP-CX copy.app/Contents/Resources/vDos.app/Contents/Resources/drive_c/Program Files/vDos/’’’
Also, one of my applications gave me an error "Not authorized to send Apple Events to the Finder" - and this error persisted even after I turned off the new backup system and restarted my machine. The only way I could recover was to delete my entire Catalina data partition and restore it from a backup.
So I won't experiment with this again. Basically, the new backup system rendered too many of my applications unusable. But you can experiment with one of the applications that caused the problem. They're not ready for public distribution, but I'll be glad to send download links if you'll send me a private message.
Essentially, the problem seems to occur because shell scripts have trouble parsing paths with parentheses. If you didn't use parentheses in the path names, this problem might not occur.
EDIT: I don't know of any commercial apps that cause this problem; I've only seen it with the applications that I make available for running MS-DOS emulators like DOSBox-X and vDos. I found the problem when running an experimental new version of the app on this page: