I didn’t know what to do so I let it run.
#DROPBOX AS BACKUP SOLUTION FOR MAC MAC#
This was wrong, as I had fully sync’d my DropBox folder on my Old Mac before the Migration. So then I started DropBox, and it appeared OK until it notified me that there were tens of thousands of files to be sync’d.
#DROPBOX AS BACKUP SOLUTION FOR MAC FULL#
I had to use a tool to set all items in the Shared/DropBox folder to give me ownership and full read/write permissions. So, I immediately paused/stopped the DropBox process, and reconfigured it to use the existing DB root folder in “Shared” folder.īut that was not good enough because the permissions in the “Shared” folder were not proper.
I ran into a similar issue last year when I migrated all of my Mac apps to a new 2019 iMac-27 using the Apple Migration Assistant from my “old” Mac. 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?Īlso, 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.)Īgain, 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. Needless to say, if Dropbox offers to back up your Mac desktop, documents, and downloads folder, don’t do it. I had to reinstall Catalina to make it work, but everything in my user folders was intact and functional. 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. 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.”Īfter 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. 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). 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. 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. 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.
0 kommentar(er)
