Warning about new Dropbox Mac backup feature

#1

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.”

Details here: https://www.dropboxforum.com/t5/Dropbox-files-folders/How-to-enable-desktop-and-downloads-syncing-in-beta/td-p/404970

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.

#2

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.

On my Old Mac I had previously customized DropBox to use a non-standard location for it’s root folder – the /Users/All Users/Shared folder.

So after the migration was completed, and Dropbox started up on my new iMac-27, Dropbox was confused and did the following:

  1. Wanted to create a NEW DropBox root folder in my user’s Home folder
  2. Could NOT access all of the files in my old DropBox folder in the Shared folder.

So, I immediately paused/stopped the DropBox process, and reconfigured it to use the existing DB root folder in “Shared” folder.
But that was not good enough because the permissions in the “Shared” folder were not proper. 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 then I started DropBox, and it appeared OK until it notified me that there were tens of thousands of files to be sync’d. This was wrong, as I had fully sync’d my DropBox folder on my Old Mac before the Migration.

I didn’t know what to do so I let it run. Fortunately DB soon recognized the files were actually already in sync, so did NOT had to do any actual file transfers in order to sync. After about an hour of running, Dropbox finally notified me that “all files are in sync”. Whew! Dogged a bullet! :wink:

I’m still not sure what is the best practice for DropBox when using the Apple Migration Assistant. If anyone has any thoughts on this, please post.

#3

How did they do this?

#4

These are scripts that I use to run emulators like SheepShaver or DOSBox or vDos. The scripts build configuration files and plist files for launch daemons, and those need to include paths that will be different on every system. The lines in the configuration files and plist files that don’t need to be changed are stored inside the applet, and copied like this (I know that I shouldn’t be using Resources/Files, but I started writing these scripts before I knew better):

set thisApp to (path to me) as text
set resourcesFolder to (thisApp & "Contents:Resources:") as text
set filesPosix to POSIX path of resourcesFolder & "Files/"
set scriptPosix to (filesPosix & "vdosfolder.scpt")
-- much other stuff
do shell script "cp '" & filesPosix & "/plisthead.txt' '" & filesPosix & "org.wpdos.vdosfolder.plist'"
do shell script "echo \\<string\\>" & scriptPosix & "\\</string\\>>>'" & filesPosix & "org.wpdos.vdosfolder.plist'"
do shell script "cat '" & filesPosix & "/plistmiddle.txt' >>'" & filesPosix & "org.wpdos.vdosfolder.plist'"
-- more lines to build the rest of the file

When the filesPosix variable has a parenthesis in it, the script fails with an “Unrecognized token” error.

My guess is that are far better ways to do this than I’m using, but I’m too inexpert to figure them out.

#5

Jim Underwood - the only way I’ve found to get Dropbox working reliably after copying its folder to a new system (or restored system) is in my post here:

It’s not the same situation as yours, but it clears the decks so that you can set things up exactly as you want them.

#6

Thanks, @emendelson.
If I understand your approach from the link, it is basically the same thing as a clean install of DropBox on a new Mac, a download ALL of the files from the DB Cloud.

I’m hoping for a solution that works with Apple Migration, which copies all of the DB files from your Old Mac to your New Mac, to avoid the lengthly time (days maybe?) to download all files from the DB Cloud.

#7

I don’t know whether it will help or not in this case, but you should never pass a path to a shell script without using quoted form of.

#8

@JMichaelTX - No, you don’t have to download all the files. The steps are these.

  1. Create a temporary folder and drag all your downloaded files from your Dropbox folder into it.

  2. Reinstall Dropbox, and tell it to use whatever folder you want (NOT the temporary folder you created in step 1).

  3. It will start downloading your files from the cloud. But you then simply drag all the files in your temporary folder into the new Dropbox folder, and Dropbox won’t download them from the cloud.

I have 120GB in Dropbox. The last time I used this method, I was back to normal in five minutes.

1 Like
#9

In that part of the script I seem to be using single quotes in the string instead of “quoted form of” as I do everywhere else. I can’t remember why I did that, but I suspect that “quoted form of” would have avoided the parenthesis problem. I’ll try reworking those lines. Thank you.

EDIT: I replaced all the single quotes with quoted form of, and the script works correctly from a normal folder. But it doesn’t work from a folder with parentheses in the folder name. I have a line in the script that uses “defaults write” to put a path in a plist:

With a parenthesis in the folder name, this produces this error, whether I use “quoted form of” or single quotes:

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.

I tried putting “quoted form of” the path within single quotes, and that produced this error:

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/’’’

I really don’t want to use parentheses in a folder name, but if Dropbox is going to do so, it would be nice to be able to work with it.

#10

OK, thanks for the clarification. That’s great! :+1: