171–180 of 238 posts
My guess is that engineering resources have been focused on the upcoming new version of drive, and are ignoring difficult bugs with the current version. I could understand that in a smaller company, but seems poor at Google scale. OTOH, that scale also means they don't care about losing a few customers over something like this.
Two things i do not get: - Why can't Google figure out what the conditions which trigger this issue are and add a caveat to the documentation? "Bad things will happen if you use more than 500,000 files on a 32 bit client." This would save both their support organization and their customers a lot of pain. - Why does this particular user not give up on Google Drive if it does not work for him, or at least try to figure…
> Why can't Google figure out what the conditions which trigger this issue are and add a caveat to the documentation? You can't fix software breakage by adding mentions in random documentation pages. Bad things shouldn't happen if you have more than 500,000 files. And if such things are unavoidable due to limits that are out of Google's control, like from the operating system or the CPU architecture, then the softwar…
Earlier quoted context omitted.
I realise that you probably aren't able to contact the customer yourself, but someone needs to tell the guy clearly what Google thinks the issue is (support saying "according to an entry on the help forum..." isn't exactly conclusive although at least they're trying), refund him for the six months, and suggest any possible workaround. Because there's no direct contact from anyone beyond level 2 support, the guy is st…
>probably aren't able to contact the customer yourself AKA don't have the courage to do it.
The customer has unfortunately left zero details with which to contact them - my details are on HN, anybody is free to PM me, and I'm happy to see what I can do internally.
Why is this story being censored? Because it puts Google in negative light? We don't see much censorship when other companies are put into spotlight over horrendous customer service.
Earlier quoted context omitted.
Of course they should work. You're making a false equivalence, though. A video game is a product that you've paid for. The user in this case is not paying for the app, they're paying for the service. Just because Google offers the app to use with their storage service doesn't mean that their support should refund money to the user when the service itself is functioning exactly as advertised and intended. My contentio…
The customer made a decision to use a particular storage platform due to the features that are advertised. One of those features is a desktop client. If the desktop client is failing, then he's not getting what is promised "on the box" (or in the feature set advertised on google.com). They sell that client pretty hard btw: https://support.google.com/a/answer/2490101?hl=en To use the full power of Google Drive, you sh…
The issue isn't so much as the client is failing - but that it wasn't designed to handle their edge-case - and trying to sync 700,000+ items, or 700GB worth of files to your desktop is definitely at the edges.
Other desktop sync clients (e.g. Box.net or Dropbox) exhibit similar performance characteristics - e.g. Dropbox advertise a limit of around 300,000 files (https://www.dropbox.com/help/space/file-storage-limit). So this isn't something specific to us.
For us, I know there isn't a hard limit per se, but there are memory limitations, due to this being a 32-bit binary. So things like the user's environment, and the length of certain fields could also play a factor.
However, it is something that I know several smart people are chipping away at steadily - in fact, there's a new "Backup and Sync client" we announced a month or so ago, which is launching any day now. It's basically Drive Sync Client 2.0.
Two things i do not get: - Why can't Google figure out what the conditions which trigger this issue are and add a caveat to the documentation? "Bad things will happen if you use more than 500,000 files on a 32 bit client." This would save both their support organization and their customers a lot of pain. - Why does this particular user not give up on Google Drive if it does not work for him, or at least try to figure…
I'd be amazed if paying customers weren't given 'slightly' better service, and that'd just make things more difficult dropping back to the lower tier?
Earlier quoted context omitted.
I'm not sure what value that would add here... 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 file…
1. Read list of files present on remote & write to file A 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.
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.
Earlier quoted context omitted.
Perhaps.. but Dropbox is not without its own issues. 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 s…
Shouldn't you be using something like Amazon S3 at that scale?
Earlier quoted context omitted.
You are forgetting about monitoring for changed files to resync those quickly.
Get notification of file change, binary search the list of files, make adjustments. This can also be done on a small amount of memory, independent of file count. 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
Earlier quoted context omitted.
>probably aren't able to contact the customer yourself AKA don't have the courage to do it.
That's a bit disingenuous. It's also quite easy to take cheap potshots behind the anonymity of pseudonyms. The customer has unfortunately left zero details with which to contact them - my details are on HN, anybody is free to PM me, and I'm happy to see what I can do internally.