{"id":6238,"date":"2019-02-04T04:04:39","date_gmt":"2019-02-04T12:04:39","guid":{"rendered":"https:\/\/www.coretechnologies.com\/blog\/?p=6238"},"modified":"2023-01-07T17:36:41","modified_gmt":"2023-01-08T01:36:41","slug":"dropbox-selective-sync-popup","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/software\/dropbox-selective-sync-popup\/","title":{"rendered":"Watch out for Dropbox Prompts when Running as a Service!"},"content":{"rendered":"
\"Dropbox<\/div>\n

Are you running Dropbox as a Windows Service? Do you rely on Dropbox to operate unattended in the background, synchronizing your important files 24×7?<\/p>\n

If so, then be on the lookout for the new Selective sync warning dialog<\/a> — a popup window that requires your confirmation whenever a file is deleted. Left unanswered, it will stop Dropbox dead in its tracks<\/b> and prevent all future synchronization!<\/p>\n

Delete from your account and all devices?<\/h2>\n

The warning was introduced in Dropbox version 51.4.66<\/a> (June 2018). It looks like this:<\/p>\n

\"Dropbox<\/a><\/div>\n

Checking the Don’t ask me this again<\/b> box will eliminate the warning going forward — a welcome capability. It’s certainly an improvement over having to dismiss the window on each delete! Thanks you, Dropbox developers, for providing the checkbox.<\/p>\n

But having the only control in the warning itself means that we can only make the “don’t ask” selection when the warning is triggered<\/b>. And who knows if we’ll be around then?<\/p>\n

Unfortunately Dropbox (and AlwaysUp) user howeboards<\/a> has fallen victim to the prompt. He describes the situation in this support forum post<\/a>:<\/p>\n

\n On the server, the Dropbox account “A” as configured under AlwaysUp in “service” mode is configured to run under the same Windows administrator account as what it would be if one was to log in to the server. It is still the same user account that it is “running as” in either case with the same configuration and the same Dropbox directory location. <\/p>\n

Because this server is hosted in Azure, is taken off-line overnight and\/or might reboot, it is not ideal to have to log in to the server to make sure Dropbox is running. So the permission issue I mentioned is because an automated process deleted a file or moved a file, and no one was there to click a dialog regardless if it was running in the foreground or the background<\/b>. To work around this, I have had to manually restart Dropbox in that user’s foreground session to click the dialog to make it remember it. That is just plain crazy.\n<\/div>\n

Crazy indeed! We can surely do better.<\/p>\n

Any Dropbox developers reading? Please implement one of these alternatives for future warnings<\/h2>\n

In addition to the graphical controls in the warnings, can you please include viable options for those of us running Dropbox unattended?<\/p>\n

Here are some suggestions to avoid those unwelcome prompts:<\/p>\n

    \n
  1. \n

    Add a specific option to the settings window<\/h3>\n

    Add a new checkbox labeled “Don’t warn me when deleting files”. Checking it would eliminate the warning without having to interact with Dropbox at some obscure time.<\/p>\n<\/li>\n

  2. \n

    Add a general “Don’t warn me” option to the settings window<\/h3>\n

    This broad setting would apply to all current and future warnings — not just the specific one raised in this article.<\/p>\n

    Such a powerful control may seem reckless, but I can assure you: Many of your customers would happily avoid any confirmation<\/u> that has the power to cripple synchronization for several hours!<\/p>\n<\/li>\n

  3. \n

    Introduce (and document) a registry value that governs the warning<\/h3>\n

    This approach puts technical folks in the driver’s seat, but with zero impact (and complexity) on the user interface.<\/p>\n<\/li>\n<\/ol>\n

    \n
    \n\n\n\n
    Read more articles about Dropbox…<\/nobr><\/span><\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n