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.