Hacker News Reader

Comment by victorhooi | Hacker News Reader

I am on that team =).

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.

View on HN

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 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.

>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.

Zero details? Surely you have his email? How else is the Google support person he's talking to able to reply to him?

I think he means "on that list", not in actual comms with google.

The person I'm replying to said he works on the Google Drive team, so I presume he also is able to get the actual comms between Google and the customer.

Not necessarily, at least easily. Customer comms often contain PII, so they're not just widely available to anyone interested due to privacy concerns. Unless you're on a ticket related to that specific customer's issue, it's very hard to get that info (and it should be.) Even then, PII like the email address may be obfuscated in the ticket.

This is my annoyance with the OP - they're a very clear edge case and, technically, the product still works for them. They're not paying for a Windows or Mac app, they're paying for online storage and that part of the service works fine. They can still access all their files via the web browser and they can add and download files as they see fit. The issue with the app is probably exactly what you're mentioning and the person is acting like the service they're paying for is broken. It's not broken, they're just using the service in a very non-standard way.

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.

No, Google Drive is sold as a customer-facing service and customers have a basic expectation that it will do what it says on the box. If the Dropbox application didn't run, I'd be pissed too, even if it does happen to be "online storage".

If someone was complaining that an Amazon S3 application was broken, that would be a different story.

If you read above - Dropbox does exactly that...

> 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).

That seems like a ridiculously small number of files at which to start encountering problems. I would expect Google to make things more scalable. Yes I realize you have to work with what the OS gives you, but still, you can build your own stuff on top of that, no?

Keep in mind this is a 32-bit system.

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.

Well, if only we had high-performance data-retrieval systems which were accustomed to limited memory on its 32-bit host. A system like that might be able to stream indexes from a HDD to a couple processes in memory which read it as it comes through. Or even just a successful full-table scan.

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.

It does do what it says on the box. You're not required to download any of the apps in order to use Google Drive. My contention is that the OP claims that they deserve some kind of reimbursement because "they're paying for it" but the "it" here is not the app, it's the service. They're paying for online storage. There are several ways to sync your files to that service. The Google Drive app is a free option. He's paying for the service, not the app.

Note that even you said "service" in your description of what it is.

The syncing apps are absolutely part of the package.

They're a part of the package but they are not what the user is paying for. If free users and paid users both have access to the app, then it's not a paid feature. People aren't paying for the app, they're paying for the service and, at least in this case, the service is still working.

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.

No. It's literally "Store, sync, and share files easily." [1]

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.

[1] https://gsuite.google.com/products/drive/

And it does exactly that for 99.9% of users. The app is not what the user is paying for, though, and he doesn’t deserve a refund just because it doesn’t work for his particular situation.

If free users and paid users both have access to the app, then it's not a paid feature.

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.

Drive is terrible then if what it says on tje box can’t deliver working sync clients. Dropbox delivers working sync clients out of the box, even though you could just use their web interface.

Save for the fact the Dropbox client wouldn't work for this user, as it maxes out at ~300k files while this user has more than double that. This user would have similar issues with the Dropbox sync client as they're having with the Drive client.

First off, I'm not sure why everyone is using the phrase "what is says on the box". There is no box for this service. Services don't come in boxes and the website doesn't say anything about paying for an app. You're paying for the service and the service continues to work. If you don't like the app and that makes using the service so much of a challenge, use another app with Google Drive or switch to Dropbox. The OP clearly has to use Google Drive because Google is the only service that offers unlimited storage space and they just want to be the squeaky wheel by falsely equating the app with the service that they're actually paying for.

You're making an extremely nitpicky and useless distinction. If a service provider offers native clients for a set of supported platforms, for use with their storage service, a natural and reasonable expectation is that they will work.

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.

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 contention is 100% with the OP's insistence that they deserve a refund because they're "paying for it". They're not paying for the app and the service is working so why is a refund in order?

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 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.

That's a mis-framing of the situation.

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.

seems like if there's a limit to the number of files the client can handle, the client should warn you as you're approaching that limit, and ideally block you from adding too many.

If the client allows you do do something, and you do it, and it causes the client to break, that is 100% a "failure"

They might be an edge case but in that case the problem is that the client crashes without any explanation. If it had displayed an error like "Sorry, the Google Drive client does not currently more than 700,000 files - you may use the web client instead" and exit, that would have saved a lot troubles to this user.

Also why can't the support tell him that directly, instead of the endless vague explanations.

Then Google support needs to tell him that and tell him to stop doing that, and if he doesn't like it, he can get a refund and go somewhere else. Not this five month garbage runaround BS support nonsense.

It seems they already have otherwise we wouldn’t even know what the limit is for the files.

> "... is trying to sync it with a 32-bit client".

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!

> we are aware of the issue, and are definitely working on 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...

[3] https://gsuite.google.com/whatsnew/calendar/

Correct =), there are many improvements in the new client (landing soon), and there are further ones coming in the pipeline shortly after.

> trying to sync it with a 32-bit client...

How can you write that with a straight face when the 32-bit client is in fact the only client?

wouldn't it be a good idea to at least raise an error message if the client handle the number of files? it would alleviate the mystery and a lot of frustration.

This has almost nothing to do with the technical problems and everything to do with the fact your support is a joke. The fact that was not addressed in your post only strengthens the argument.

A 32-bit client can only handle 300,000 files? Could you imagine if 32-bit windows fell over at that level. Is it storing every file in RAM?

Reply on news.ycombinator.com