This is a Bug Report + Idea
Hey, how about having your "autoupgrader" script test the target platform for dependencies before foisting a lousy upgrade down paying customers throats and breaking their production machines which support millions of users.
#2 Nobody on the production machines uses QT, nor has X access, so why is QT being depended on when no DISPLAY environment is set?
#3 Thanks for forcing GLIBC 2.9 requirements down, 2.9 adds little to no value over earlier and more common 2.6 except minor syntactic sugar. So of course the autoupgraded dropbox couldnt start in the middle of my testing services for no apparent reason, except after wasting an hour of my time, I discover it's because it doesn't like 2.6 anymore. So I use our custom 2.9 build, and thats when I discover it complaining about your QT lib too:
ImportError: /root/.dropbox-dist/dropbox-lnx.x86_64-30.4.22/libQt5Core.so.5: undefined symbol: g_main_context_push_thread_default
Why is a commandline instance calling out to QT and then failing?
How about stopping telling us about "permission errors?" The only solution you have is to reinstall, which ultimately wipes the Dropbox directory and wastes our paid bandwidth downloading 200G of data that was already excluded.
I am VERY ANGRY. This "agile" development method produces software that ranges between awful to absolutely abysmal, filled with halfwit, un-back-tested assumptions that ultimately waste customer time and money.
Hey, how about using multiple virtual machines in different configurations to backtest all platforms at once? Then your dev team would have instantaneous feedback about what breaks.
Hey, how about having the dropbox app report the libraries in use to HQ, so you guys know how many users you're screwing over with each unbaked update.
I see the DbxSvc logging thing is still happening, however for those interested, there is an update/explanation from DB here:
at least you reduced the frequency:
Failed to connect to the driver: -2147024894, retrying in 1800000 milliseconds
from every seconds, to minutes you changed that to 30 minutes, but why ???
based on the above mentioned link to another post (thanks for that), the answer from dropbox (thanks for the answer)
> It should be failing to connect. This is by design, the actual issue you’re facing is due to the frequency we're writing to the logs.
really? so do you keep you trying, again and again?
option 1: once every startup/boot (or actually every new release, as you keep on updating without known cause) should be enough, because sure nothing will have change in the mean time ....
option 2: as, based on your answer, it is only relevant vor dropbox business users, do not executed it at all for all others (what an innovative idea ...)
Oh, and it got re-enabled again, I disabled it again