Spend the $10/month. Don't go on for more than half a year with your storage being broken.
Disclaimer: no affiliation except a satisfied pro account user
EDIT: Edge cases notwithstanding.
I tried diligently to get Dropbox after hearing statements like yours. I signed up and added my dataset, 600GB of ~670,000 objects. It never would sync, used 10GB+ of memory while "preparing" to sync and ultimately crashing.
I use Google Drive now, and it's not without its issues, but my data is synchronized.
I'm not saying Dropbox is a bad product; I'm trying to show that every product has issues.
My attempt was circa mid-2016.
They have an issue where it works fine but they log an "informational" error in the event log every second. It's been well reported on the net.
Not fixed. I logged my own support case with the full details and they don't know what the Windows Event Log is.
It's inexcusable. I understand having juniors work on a help desk. But not people who can't even search their own ticket system for similar issues and don't know the first thing about computers or software.
No, thank you.
for example: http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...
I'm surprised it's not like windows where the prompt is displayed with everything else dimmed so you know it's the real prompt, and on a secure session where it can't be manipulated by other applications.
The customer's issue seems to be that they have a very large number of files, and are trying to sync it with a 32-bit desktop client, and are hitting memory issues.
Dropbox themselves state this on their websites:
https://www.dropbox.com/help/space/file-storage-limit
> Note: The performance of the Dropbox application may start to decline when you store above 300,000 files.
I've done some comparisons across various companies sync clients, and it is a tricky problem.
(Disclaimer: I work for Google).
2. Read list of files present locally and write to file B
3. Sort files A & B
4. Read files A & B to update remote and local files
This can be done with less than a meg a memory.
There's a lot of nuance involved here - and the fact you have to do bi-directional sync, with a reasonable expectation of "real-time" makes it tough as well.
Also - the fact that other desktop clients (e.g. Dropbox, Box.net) exhibit similar performance characteristics (e.g. Dropbox advertises a 300,000 file limit - I believe this customer was going on 700,000 files) would also probably indicate it's not quite that simple.
The user has 700000 files. Each is probably >10 char of UTF8.
In step 4, you also want to catch things like the user moving 50000 files to a new subdir, or renaming a top level subdir, while the sync app is not running.
I'm sure it's tricky to update the existing software, but as a generic problem syncing files with O(1) or O(logn) memory is not very hard.
While rescanning, the files may continue to change. You may or may not get a subsequent event for a file that changed during your rescan.
One example of related issues: https://github.com/libuv/libuv/issues/626
(I've been very slowly designing my own, and the first thing for me was coming up with a list of awkward cases ..)
I guess I was unclear here. It's hard to make a polished user application. The not-hard part is just the core algorithm selection. I have enough minutes in the day to consider algorithms, but not enough tens of hours to write suites of quality software products.