Would be amazing if that's actually true and it turns out they discovered some huge underlying issue with the system from the user logs that they've actually had a team working on... but I'm sure it isn't. For a start if an issue like that was being worked on surely they could contact you to let you know.
I won't say much publicly, but if this is the issue I think it is (customer has a huge number of files, and is trying to sync it with a 32-bit client, and hitting memory issues), we are aware of the issue, and are definitely working on it.
It's a tricky thing to solve in any sync client - for example, Dropbox has a cap around 300,000 files (I believe this customer had 700,000 files?):
> 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.
Other clients may have similar limits. I'll see if I can find our docs on it.
Disclaimer: I work for Google.
Because there's no direct contact from anyone beyond level 2 support, the guy is stuck in limbo without being able to know where his issue is in the realm between "about to be fixed" and "never."
On the other hand, it's nice that there is actually a team on this and that it's not just support palming him off. Problem is there's no way for the guy to know that. If I keep telling you that Santa is urgently working on some presents for six months eventually you're gonna stop believing.
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.
Edit: Since people seem to be voting my comments down, I'll offer an analogy. This is like a professional bowler going to a family bowling alley and complaining about the balls they provide for you to use. These same balls work for 99% of the people paying to bowl. You don't deserve a refund because you're an edge case from all their other customers since the actual bowling alley is still open and you can still bowl, it just might not be a great experience. Get another ball, bring your own ball, or stop coming to this bowling alley.
If someone was complaining that an Amazon S3 application was broken, that would be a different story.
Note that even you said "service" in your description of what it is.
If the OP was actually concerned with finding a solution to their problem (which is absolutely an edge case) and not just being a squeaky wheel, they'd pay $30 for InSync or find another free tool that syncs with Google Drive. The Google app is a bonus provided by Google to make the use of their service easier. The OP complaining about being a paying customer is pointless because what they're paying for is still completely useable.
There is no way to sync a device without an app. The app is not a bonus, it is a core feature of the service.
You just assert this as if it was self-evident, but it's not. The same feature can be offered for free and as a paid component of a package, just like the same code can be licensed to some under the GPL and to others under a proprietary license.
In this case, syncing is part of the service being purchased, and the means to achieve that is absolutely part of the package, even if it's also offered for free to others.
If a video game publisher sells a game for Mac and Windows, and one of those platforms doesn't work, then the affected customer is entitled either to customer support or a refund. The advertised product (native client on a certain platform) isn't working as advertised.
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 should install Google Drive for Mac/PC, a desktop sync client. This synchronizes any or all your files to Google Drive on the web, making them available anywhere, at any time, on any device. It also provides secure, cloud-based storage for your files.
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.
If the client allows you do do something, and you do it, and it causes the client to break, that is 100% a "failure"
> https://www.dropbox.com/help/space/file-storage-limit
They claim a limit of around 300,000 files - this user apparently has 700,000 files.
The Google sync client doesn't have a hard limit per se, but yes, the performance does similarly decline after a certain point - it depends on a number of factors, but it's possibly at 700,000 that you would see issues. It should be able to comfortably handle 300,000 though.
In fact, most Desktop sync clients experience similar things.
I do know this is something we're aware of and are actively improving. In fact, we have a new Backup and Sync client that we announced recently and should be going GA shortly.
There's no details I have to contact this specific customer to see if I can intercede, but if anybody knows, please comment here.
(Disclaimer: I work for Google, but any comments above are my own).
As a result it has at most 3.5 gigs of memory for the entire system, and e.g. on windows this will limit a single process to 2 gigs. If the sync client keeps some kind of in-memory representation of your files (a very reasonable thing to do for the vast majority of clients), and if you have 700,000 files, and assuming that folder references magically take up no space and that the sync client uses no other memory whatsoever, that's less than 3k per file representation before you crash.
If that is indeed contributing to the problem, it's most likely just a case of doing what's optimal for normal workloads, and simply not having engineered a backup solution for cases which fall so far outside of your expected usage that it didn't seem worth considering at the onset. This kind of change would also be very non-trivial to engineer, likely requiring a rather large amount of refactoring.
We could call it "Postgresql". Or even "Sqlite".
"Well, because it is submersed in a marine environment, I've always called it the Going-Under-The-Water-Safely Device."
-- Leonard da Quirm
RDMBS are the "accesses-the-data-safely" device. This is a failure of architecture.
Also why can't the support tell him that directly, instead of the endless vague explanations.
Upon reading this I got the impression that the issue was [customer] using 32 bit Windows and therefore not able to use the 64 bit version, however checking out e.g. https://www.quora.com/Is-there-a-version-of-Google-Drive-in-..., and also installing google drive myself right then seeing it appear in C:\Program Files (x86)\Google\Drive, there's clearly no 64 bit version of Google Drive available at present date (2017-07-10).
Perhaps giving alerts when hitting usage limits would be of help to customers with such a high amount of files. Best of luck resolving it!
I am guessing the fix for this issue would be to download the new Google Backup & Sync app [1][2] that replaces the current Google Drive client and is meant to be released on Wednesday [3]? :)
[1] https://gsuiteupdates.googleblog.com/2017/06/backup-and-sync...
[2] http://www.androidpolice.com/2017/07/01/googles-updated-driv...
How can you write that with a straight face when the 32-bit client is in fact the only client?