Hacker News Reader

Comment by laurentoget | Hacker News Reader

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 out what is making it choke and avoid that edge case? It is not like it is the only cloud storage solution out there and finding a new one cannot be more painful than this endless BDSM dance with support.

View on HN

> 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 software should warn the user well in advance before any damage occurs.

Google has all the manpower it needs. But this is again one of those instances where they show how little they care. Which should have been obvious by now, given that with all of their manpower and virtually unlimited resources, they still haven't released a Linux client.

This is why I'm staying on Dropbox btw. My data is too important for me to entrust a company that will sell cloud storage as a complementary to something else.

> Bad things shouldn't happen if you have more than 500,000 files.

No one in the world has a solution which works for this case. I think the best thing for Google to do here is to document it like dropbox and get out of the blame game.

if they cared they could fix the bug too.

Google is now a huge, slow corporation.

you don't get promoted by working on old and boring projects. everyone fight to get into the new sexy rewrite of something that is already somewhat successful. yeah they can screw up and kill features, but users will continue to use ensuring your promotions.

in a huge corp, do not assume that just because the little support guy understand your pain, the engineers behind will move a finger.

>> Google is now a huge, slow corporation.

They have been huge and slow for many years. Google Drive is non-core for them, which doesn't help. They probably have the data on "number of files per user." But if you are too far into the tail, they probably care little. Now if this were an ad-related issue....

We do care, and it's certainly something we have been actively working on.

However, the fact that other desktop sync clients from other providers exhibit similar performance characteristics possibly indicate that it's not as easy to solve as a naive first pass would assume.

> that it's not as easy to solve as a naive first pass would assume.

Because Google doesn't have the resources to tackle challenging problems? lol.

A difficult to solve problem on its own is one thing, but the comically awful support Google offers indicates that it's more likely a "we don't care" versus a "we don't know how" problem.

Somehow it's starting to feel like Google is the Bell of the 21st century, and this sketch has stood the test of time surprisingly well https://www.youtube.com/watch?v=CHgUN_95UAw

We don't have a monopoly on clever CS people =). I'm pretty sure Dropbox and Box.net have lots of smart people working for them as well. (In fact, I have friends at Dropbox)

I'm not an expert in that specific bug, so I won't speculate publicly - but the memory issue is something that has seen steady commits over time from various people who are plugging away diligently at it. It's a bit of a moving target, and there is a tradeoff. The customer's case is a bit of an edge case, and at the extreme end of things.

In terms of the customer support side of things, I don't know all the specifics of what happened, so I won't comment further. However, my details are on HN, so feel free to PM if you want me to see what I can do internally.

> I'm pretty sure Dropbox and Box.net have lots of smart people working for them as well. (In fact, I have friends at Dropbox)

While I cannot say anything regarding Box.net, the Dropbox app on Windows is one of the best working programmes I have installed. It has never crashed and doesn't slow down my computer, no matter how much it has to sync. I never understood why Google isn't able to copy Dropbox behaviour even after years. GDrive is still able to slow down my computer notably if I sync a lot of files and it tends to lose the connection every week or so until I restart it.

If you then look at how reliably Google Search or Gmail work, the answer can just be that Google doesn't care, not that they couldn't do it.

> In terms of the customer support side of things, I don't know all the specifics of what happened, so I won't comment further.

What possible reasons could there be for your support team denying the refund that may have been left off that page? Hypothetically speaking.

> In terms of the customer support side of things, I don't know all the specifics of what happened, so I won't comment further. However, my details are on HN, so feel free to PM if you want me to see what I can do internally.

What possible information would you need? You are basically saying you don't trust OP's account of what happened.

In any kind of user-facing support role, not trusting the user's account of what happened is rule #1.

We do care, and it's certainly something we have been actively working on.

Did you read the time line? Even if his issue is directly being worked on, which is doubtful if you look at how many layers of clueless tech support this apparently goes, this is terrible customer support. If you promise to reply in 48 hours, reply in 48 hours. Give the customer compensation for the months the product did not work properly and maybe a gift voucher for all the effort they put into helping to solve this bug.

I never used drive, despite my employer subscribing to the whole Google drive thing just for hangouts (which only recently allows more than 11ppl)

but a friend maintains a studio and they use your biggest competitor. they sync over a million instrument sampler files per composer. granted that the initial upload and new drive takes almost a week working exclusively on the first sync, but after that it works.

I don't profess to being an expert on this issue - but it's a bit more complex than simply "We don't work at X files". There's a bunch of factors, including the user's own environment, and lengths of certain fields that can affect what the exact limit is. Memory is a moving target.

Other clients exhibit similar behaviour - e.g. Dropbox states a limit of 300,000 (https://www.dropbox.com/help/space/file-storage-limit), and from my own informal testing, I know Box.net also exhibits odd behaviour as well.

(Disclaimer: I work for Google, but the above comments are purely my own).

Why don't they give up? I can't imagine that's going to help their case getting refunded?

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?

How much time are you willing to spend emailing a broken customer support organization to run after a refund?

Reply on news.ycombinator.com