Dropbox ignores user's complaints of poor performance for almost a year
dropboxforum.comDropbox is in my opinion synonymous with poor performance. The client always consumed way too much CPU. On a Mac, Dropbox will react to changes anywhere in the filesystem, and consume excessive amounts of CPU even if the files you work on have nothing to do with Dropbox. If you use selective sync, stuff that lands in folders not synced to your computer will still cause Dropbox to consume CPU.
Storing a lot of files inside your Dropbox will also cause performance problems. Which means that paying for extra space (I do) isn't that useful if you intend to keep your git repos with source code there.
It has been like that for years, the company has made little progress performance-wise (instead we got useless things like photo-something-or-other-that-tries-to-access-my-photos).
I learned to live with it, because the advantages of Dropbox outweigh the disadvantages of a poor implementation. Dropbox is still a very good product, even if you have to pay a hefty price in CPU and battery life for it. I dream that one day someone will decide that performance is a goal worth pursuing and finally optimize the thing.
Why would you put your git repo in DropBox? That seems counter-intuitive to me. I specifically keep anything in a VCS out of DropBox since then you're versioning stuff twice....
I have just under 150,000 files in DropBox and haven't noticed any performance issues. DropBox rarely shows up in Activity Monitor's first 20 CPU users (unlike MediaFire which is usually burning CPU for no reason and only managing 200 files).
Perhaps it's an OS difference? I am on OS X 10.11.1.
Dropbox = real time, automatic, versioned backup of all files in your entire project, making you and your work safe from deleting files, accidentally overwriting files etc, all the time.
Git = not that.
Have you ever tried AeroFS?
I store my whole workspace on Dropbox (minus some sensitive projects which are in my tarsnap-workspace). Every single one of my projects starts out with
>> mkdir projectname && cd projectname && git init
but not all of those projects end up on github/online repos.
Regardless, git is not backup, and dropbox isn't (real) versioning.
Regarding Dropbox reacting to changes anywhere in the filesystem: I found that turning off everything under "Import" in preferences seemed to stop it. After that it was perfectly fine on an old 2008 Macbook with spinning disk hard drive. Anecdata, but worth checking.
I haven't used dropbox for a year but it told be specifically not to try and sync git-repos via dropbox when I tried, because it would have performance impact and could result in unexpected behaviour.
Poor performance, broken in Windows when using roaming profiles, storing binaries in the user's roaming AppData folder on Windows, DLL injection in Windows and god-knows-what in OS X to alter Explorer & Finder icons, low base storage.
The only thing Dropbox has going for it is that somehow, everyone else is worse. Core syncing and client reliability is just trash across the board for all the other providers. But Dropbox is still infuriating.
They were injecting code in to the Finder too. No doubt this is why Finder Sync Extensions[1] were created, because it's a support nightmare. (Well, and also because that code injection vector was eliminated in El Capitan.)
[1] https://developer.apple.com/library/ios/documentation/Genera...
What bothers me about Dropbox is that many of the complaints I had 7 years ago are still there...
For instance, I can't exclude folders and extensions, which messes up my workflow a lot (e.g. I can't exclude .git folders)
> What bothers me about Dropbox is that many of the complaints I had 7 years ago are still there...
People have been complaining about the AppData binary thing and the roaming profiles issue since Dropbox launched.
I thought that FINALLY, after they had launched Dropbox for Business, it would come with an announcement that they had fixed Dropbox on roaming profiles and started storing the binary properly.
Nope. Just a branding initiative. I managed to screw around with it enough to get it working on my profile, but I've been unable to repeat that success, even with admin access. So, so annoying. iTunes works better in a corporate environment than Dropbox does.
As a workaround, you can tell git to use a different git-dir folder that's not within the working copy:
http://stackoverflow.com/questions/505467/can-i-store-the-gi...
You can ignore .git folders before initializing your repository [0]
[0] http://aditya.vaidya.info/blog/2013/08/25/using-dropbox-and-...
About using the selective sync dialog: it takes me about 5 minutes to just load the folder list in the GUI, and it's on a quad-core Macbook Pro with 120 Mbps internet.
I believe a perfect solution for power-users would be a support for '.nodropbox' files, which would disable selective sync for a given directory and it's subfolders.
An even better idea would be '.dropboxignore' files, using the same syntax as '.gitignore'.
Years ago I tried to buy a gift subscription of Dropbox for a friend so we could collaborate.
Still impossible.
These guys can't even manage GIFT CERTIFICATES, I'm not surprised they have trouble with actual technical issues.
Why do you take the punishment? There are tons of other storage+sync providers available.
"Sorry! Gifting isn’t available in your country yet. Sign up for notifications, and we’ll email you once it’s available."
I got the same message in Canada.
Wow, that must be brand-new. I was looking for it a couple months ago, and all I found was a million support posts about "why don't you offer gift accounts?" and a few promises that it was coming soon, really, posted back in like 2009.
I think Google is faster at file sync than Dropbox. "Best in class sync" may have been true a few years ago.
Then again no one is perfect. I've seen the green check mark missing from all my files in Google Drive at different times.
Most of us are complaining about services we use for free.
> I think Google is faster at file sync than Dropbox.
Speed of sync isn't much of a concern to me personally, I don't use Dropbox for big files. Reliability of sync is key for me, and for that I have never had an issue. Everything is everywhere, without exception. No conflicts or corruptions, period.
> Most of us are complaining about services we use for free.
I'll complain about a browser too. "Free" isn't an excuse to offer a crappy product. You're still making money off your userbase somehow.
It's also worth noting that the problems that exist with Dropbox, permiate all tiers. I'll use it, but I'd never pay for a service with so many issues unless I had a very good specific reason. For example, iCloud Sync is way worse but I'll pay for the privilege of being able to dump my iPhone photos online automatically.
I agree with your free comment, but you'll pay for iCloud when Google Photos is essentially free?
Yep, because it's built into iOS at the system-level. I also don't like Google and I generally avoid all their services except Search & Maps.
Wow, guess I'm the only one who never noticed performance issues on my Macs. I remember when Google Drive first came out years ago, the client caused the system to slow to a halt, so I stopped using it. I'm sure it got fixed, but it only takes one bad experience to kill it for a user.
Interesting thread.
I have had problems on the Mac and to some extent Windows as well. Generally the fix has been to totally close Dropbox, clear out the Dropbox cache, which is a set of hidden files somewhere (look in their support pages or Google for it) and then re-install the Dropbox application. It more than likely will do a full re-index and this is an absolute pain and CPU hog when it happens. If you have a lot of files, it can day half a day to a full day.
I'm not sure exactly what happens, but my guess is that somehow an index in it's internal database gets corrupted and then it sits in a loop there for some reason whenever it hits that file/folder.
We have used Dropbox extensively in our office across Windows & OSX for at least 2 years and have had this periodically (and randomly) happen on some machines. Although I can't recall it happening in the last 6 months or so.
There was a period where it happened almost fortnightly to someone in the office and we almost swore off Dropbox to something else.
The above has always fixed the issue for us. YMMV.
I've had a similar experience.
I've never noticed a problem with Dropbox. Of course, I'm not running tools that show me battery consumption of apps and such on my Mac. Battery lasts long enough that it's never been a problem to look into.
I also had trouble with early versions of Google Drive. Maybe it's time to give it a try again. The problem I had was that drive thought all of my files had changed every day and started syncing the entire Google Drive folder again. I removed it and haven't tried it again since.
On my macbook pro Google Drive has improved but still causes trouble and generally runs much slower than dropbox, which has always run flawlessly.
Me either, but unless the client self-updates I'm running a 3.5 year old client.
It must. I'm running 3.10.11 which the release notes say is the latest. I remember they changed their UI in the OS X menubar icon to be really crappy a couple years ago which I griped about. That's the only way I knew it was updating itself.
I've been noticing poor performance too, in addition to some weird bugs. I've had files completely disappear, the response from support is attached below. I still don't have those files back, they were not critical but now I have learned to use dropbox for (slow) syncing between machines, and use an external drive for redundancy.
Support response:
The event you've provided shows and deletion of 12 files as well as an addition of 12 files. When this happens in the exact same event, it is due to a move or to renaming a folder 99% of the time.
To recover your correct previous versions of these files, you may be able to rename the folder back to exactly what is what named prior.
Millions if not billions of users, a dozen comments on a forum. Looks like an anecdotal thing more than a widespread issue.
On Windows, Dropbox has a global file watch and does filtering to determine if the files should be synced: https://news.ycombinator.com/item?id=9136546
It seems like they do that on OS X as well.
Typical Dropbox...
I've been bugging them about a solution to the file limit for at least a year with no response. I finally got a (public) response by tweeting at them. They said they would follow up with me and they never did. Even a "we can't fix this" would be better than the dead air I've received.
I really don't know how they intend to compete with the software giant's similar offerings if it's not via superior customer service.
For anyone not aware of the file count issue you cannot have more than ~300,000 files on dropbox before it totally falls apart. I was paying for 1TB of storage and using about 3% of it when it totally stopped syncing.
inotify has a limit on how many watches can be held. I don't think that 300k limit is particular to Dropbox, any tool working on the same principle will hit that limit.
They should watch the directory, not the file.
The limit is found here: /proc/sys/fs/inotify/max_user_watches and defaults to 8K, not 300K, so I don't think it's the cause of this problem.
You're right, I was mistaken. The limit is a user limit.
I use Dropbox to sync my ~/Sites folder in OS X, between my three macs. It works.... Except when it can't figure out a conflict and creates CONFLICTED copies of git object, refs, head files. Quickly turns into a nightmare.
CONFLICTED copies in Dropbox drives me absolutely nuts, and should not happen since I never edit the files concurrently.
Dropbox also ruined one of my favorite mail client on Mac: Mailbox. Somehow they did an update from 0.4x to 0.7x which made the client orders of magnitude uglier, crash more often, have dozens of rendering issues which never happened in 0.4x. They did this without communicating anything in their blog[0], and meanwhile totally ignores all the complaints in Dropbox forum[1].
[0]: https://blogs.dropbox.com/mailbox/
[1]: https://www.dropboxforum.com/hc/en-us/community/topics/20021...
Dropbox is literally the worst app on my MacBook Air. It's such a POS, it blows my mind that Dropbox can suck so hard on a platform as important as OS X.
I had to give up syncing some parts, because the problems would create a bevy of file conflicts.
Definitely something I'd like to see fixed. What I find crazy about that thread, and something I would find unacceptable is how many people on that forum basically using it as a means to advertise for the competition (Google Drive.)
Not saying that shouldn't be allowed, but you'd think the community manager would make it a point to take that feature right to the dev team. I know its not an easy fix, but definitely something that would immediately satisfy a large group of users.
Not to mention from a 'green' perspective the amount of CPU cycles, Wi-Fi packets, etc that could be saved from fixing this.
I've been bitten by this problem too. What's extra obnoxious about it is that the client used to work just fine -- but a couple years ago it started randomly hogging an entire CPU core for seemingly no reason at all.
I still use it, but Dropbox's refusal to do anything about this problem (or even acknowledge that it exists!) is mostly what's prevented me from taking the leap to a paid account.
It's too bad, because Dropbox's speed, simplicity and (at the time) minimal performance hit was what I originally liked about it compared to other sync solutions. Now it's missing all three.
I find this very strange, as the major file synchronization client that I work on doesn't have this problem. We use the fsevents API, and it's pretty localized to the folders we monitor.
(I will admit that we have performance issues when users sync more than 100,000 files; but that's more due to fundamental limits of what you can do in a user-mode application.)
Perhaps Dropbox is just trying to trap deleting / moving / renaming the Dropbox folder? That's something that's tricky to do; and we had to disable our technique to do it because it had too many side effects.
Based on the warnings in the Console log back when I used Dropbox, Dropbox isn't using fsevents API appropriately but is instead reading from the raw fsevents firehose.
I've had my public links blocked for three years. The reason? "Temporarily blocked due to too much traffic". 3 years is temporary huh? I have even tried emailing support. No response.
I use Seafile, I've not looked at how secure it is, so I only store non-sensitive stuff on it. Its not a "Dropbox but better", its different with different controls. I use to to selectively sync folders, and preference files. Other than that I can't really say much, the mobile app shat itself last time I tried to back up photos (~2 months ago). Its wobbly, but I still prefer it over Dropbox at the moment.
Dropbox's energy performance vs. Google Drive:
http://imageshack.com/a/img908/1838/YHDwZ6.png
I only keep Dropbox because they automatically stick my screenshots in a folder and sync it.
I have to keep it closed 1/2 the time, which makes it a terrible solution for multi-device syncing and sharing files. All this in addition to laughably primitive functionality! The worst part is I pay for nothing to ever improve.
More accurate: "people keep piling into a bug thread about one symptom with many possible causes for over a year".
Ignoring accumulated customer complaints is not good customer service, regardless of what you imagine their misconceptions may be.
And they're still the only one that works worth a damn on Linux and Windows. So sadly, I'm still using them.
Though, I've never, ever had a perf problem with it.
Do any good people even work at Dropbox?
I submitted my resume years ago and never heard back. I wonder who they hired instead..
Other than Guido, of course :)
Please don't make blanket statements that discredit the work of an entire engineering team that you have little insight into. I'm sure there are strong engineers at Dropbox, the same as there are anywhere else. Statements like that are not what HackerNews is for.