New "Delete from all computers" prompt

[Jane]

It shouldn’t reset upon updating our application or rebooting @howeboards. Have you noticed this across devices incidentally or on a specific pc/ desktop? Can you include a bit more detail in regards to your setup, where this setting doesn’t comply with your choice? 

Following, to answer your question, please note that our latest Stable Build is 59.4.93. Have you updated to the latest Dropbox desktop version as expected? Any detail you could send me on this discussion in regards to your configuration would be very helpful, in order to determine what could’ve gone wrong.  

When it comes to your inquiry @RichardK26, I can see that you’re facing this issue since the feature was initially launched, therefore I’m suspecting that maybe something in your setup may be interfering & resetting your options. Are you using Symlinks by any chance (i.e. I’m mentioning that as a possible cause of the discrepancy you’re seeing, since you’ve mentioned that your settings are changing without your input). Please do let me know of your findings on this discussion & we'll take it from there. 

[RichardK26]

Jane,

Thanks for responding.  The prompts are very intermittent (maybe 3-4 times since the feature was deployed).  I think one of them was after a reboot (could have just been a coincidence).

I do have some symlinks (it's on Windows, I'd have to check if they are directory junctions or hardlinks) but they are set up as described in the article you referenced (i.e. data is under the dropbox folder, links are pointing in to that).  Also my Dropbox folder is renamed and located in a non-standard directory (not under My Documents).  Both of these things have been set up this way for years (even since I started using Dropbox) and have not caused me any problems in the past.

Let me know if you have any thoughts.  If you can find out for me which registry key (or config settings, etc) controls the prompt I can set up a monitor on it to catch when it resets, which might offer some more clues to the cause.

[Rich]

---

@RichardK26 wrote:

If you can find out for me which registry key (or config settings, etc) controls the prompt ...

---

Dropbox settings are stored in an encrypted database file and cannot be accessed or changed outside of the Dropbox client.

[Server_Align]

re: Dropbox settings are stored in an encrypted database file and cannot be accessed or changed outside of the Dropbox client.

Yeah good one, just unlike every other Windows program!

PS: And there is a second prompt when moving a folder out of Dropbox, cant they just leave well enough alone.

[howeboards]

@Jane Thanks for the prompt reply. It had been happening with a shared folder. It was happening on all the machines regardless of whether the account was the owner or had been granted access to the shared folder. It would happen periodically on a file delete or a file move. Since I first posted, all of the machines are now on the latest stable build, 59.4.93. On each of the machines, we have had to dismiss the respecitve prompts (for both a delete and for a move)  just once since that upgrade. In this scenario there are 3 machines: One is running MacOS under account "A"; one is running Windows Server 2012 (where Dropbox is running in the background session as an admin account using software called AlwaysUp so it is started like a Service but has no interaction with the desktop) under account "A"; and the third one is running on Windows 10 under account "B". For the Windows Server 2012 instance under account "A", I would also run it normally as the same admin account in the user's session and I would still get the prompts, so the fact that it was running in the background was not the cause of the issue. Dropbox account "B" owns the shared folder that dropbox account "A" has been given access to.

Going forward, I will monitor those three machines and see if the issue happens again since all three are on the same version of Dropbox.

A good tell that it has manifested iteself is when a certain file that has been deleted or updated by one of the three machines is not accessible on the other two machines and presented itself as an access / permission issue because my guess is that Dropbox has somehow locked the file pending attention to the dialog.

Hope this helps.

[Jane]

I have to admit that I'm genuinely impressed by your excellent troubleshooting skills @howeboards & @RichardK26! It seems that you've been able to diagnose the behavior really well on your end, so I'll take it from where you've left off. 

Now @RichardK26, I understand that this may sound monotonous, though I'd recommend removing the Symlinks on this device & see if this amends the behavior. Despite the discrepancy having manifested itself just recently, we’d still have to rule that factor out, as Symlinks may prevent our app from running smoothly.

Following, let me re-iterate Rich’s point above, as configuration settings can’t be modified without affecting the desktop application’s performance.  

When it comes to the behavior you‘re describing @howeboards, it would be worth noting that configuring Dropbox to work with your Windows Server may work if you run the Dropbox app as an application in a user account, instead of as a server service. (This is happening because Dropbox runs within individual user accounts rather than as a single service that many people access.) As you’ve already found out on your end, this results in permission errors, as we’re unable to find ‘file update events’ to sync changes. 

In case you decide to keep your current setup & monitor your devices on your end, please do let us know if you narrow down the causes, as it may help us further advise. 

Thanks again to both for your ongoing cooperation!

[howeboards]

@Jane: Thank you very much again for your reply. I really appreciate the open dialog.

Just to clarify, the server setup above has worked flawless for well over 3 years until this feature was introduced.

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. 

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

The permission issue is a red herring (that I should not have introduced that mainifests itself because no one is there to click a dialog) to the issue where it seems to arbitrarily continue to prompt on all three machines regardless of a human having clicked the prompt prior.  If it would have remembered the setting, the permission issue would never happen.

[Server_Align]

@Janre "When it comes to the behavior you‘re describing @howeboards, it would be worth noting that configuring Dropbox to work with your Windows Server may work if you run the Dropbox app as an application in a user account, instead of as a server service."

All services run within one account or another.

Dropbox run from a services app launched , a scheduled task outside of user login, or runas.exe from an alternative account, all still run within an account.

I would suggest for the person using it on Azure to use a Scheduled Task 5 mins post start up with a repeat at a rate equalling 25% of expected up time, or every 6 hours should the server be expected up a whole day or at all times. In this way a Dropbox app crash will be recovered from within a resonable time. A services restart only works for so long.

[howeboards]

@Server_Align: All good points, however, the solution for the server works as it is currently implemented. It has been running without incident for well over 3 years. It runs as a user account with administrative privileges. It is not running as a service account. A third party application named "AlwaysUp" makes sure that it is always running in the background instead of in the foreground. This mimics what you described with a scheduled task, but handles it in a much more efficient and robust manner.

The issue is that Dropbox prompts the user with a dialog on a "delete" or "move" of files that has to be dismissed. I should have never mentioned that part re: the server config as it is a red herring to the underlying issue of not Dropbox not remembering the previous choices. I only mentioned it with regards to how it was manifesting itself.

[Server_Align]

@howeboards nothng wrong with Alwaysup I have used it also. 

There is a launcher with the developers pack (developers? might have been some other pack) that does it as well but with less fan fare or care on crash.

The scheduled task was just a suggestion as it is natively designed to run apps.

All good tho.

And yes I know what the base problem is, with these stupid prompts.

And that is Dropbox developers dont care less about compatability with the OS.

They act and expect others to adjust to it. It was like this years ago when they had all the market share, now its ebbing away they wont change.