That's comical. I feel like I have an understanding of what's going on because I've been in this scenario on a contract - not with Google.
I was told - "there's a backlog of support requests. They are old requests that nobody has been working on and our offshore team can't handle. Being an expert in this particular product (and always in need of some extra cash), I said "OK, but let me be very clear that this is secondary to all other work that I'm doing."
Then they proceeded to hand over tickets. I wasn't allowed to communicate directly to customers, and communicating with their offshore staff was a challenge. "I need a log to even begin to troubleshoot this." followed by a frustrated customer reporting "I don't know why you're asking for this log, it won't help." OK, I have to be more clear with support, who I assumed would know. "I need this log. You create it by taking these steps." Another follow up from the customer with the same log again, reporting more frustration. Repeat this process 5 or 6 times, on 20 different tickets. I finally follow up along a different path. "Well, you see they see a request for logs and they only have one template to ask for logs. I'll get it straightened out." A month goes by. I'm getting requests for updates. I follow up on every path I have available. One customer was smart enough to get me the right logs, but they did not forward that log on. After much back and forth I ended up getting that one log. It pointed to a source code problem that I had no access to view, let alone edit. And of course, I have no contact to send this to.
What I ended up doing is submitting a bug report, the proper logs, and a summary of the logic problem in the source through one of my clients support account. Then I updated the tickets that looked to be related with "pending outcome of support ticket 1234. Months later, that particular problem was patched.
Hopefully the customers with their tickets stuck in "level 3 support" were eventually notified. I backed out of that project at some point because it just wasn't a good use of my time.
I understand the need to find a way to scale support. But if you are going to scale, monitor for effectiveness, plan for procedural changes, and do something to make sure the communications channels are working.
"scaling support" almost always seems hand in hand with "dumbing down for lowest common denominator". By the time things have made it through "please restart your computer"-level stuff, maybe the only way to scale is to put real engineers on problems and "allow" them to actually talk to the people having the problems. This approach seems to be the only one companies seem hell-bent on never trying.
I think the unfortunate truth is that "please restart your computer"-level stuff actually does solve whatever problem the customer is reporting enough that companies put value into that type of support.
If you're reading HN you probably don't need that level of support, but that's not to say there aren't customers who need their hand held to restart a computer.
> If you're reading HN you probably don't need that level of support, but that's not to say there aren't customers who need their hand held to restart a computer.
Part of the issue is that support is never allowed to push back on the customer. They don't get to say "I'm sorry, but you'll have to do a rudimentary computing course before I can proceed further". In a business environment it's all to easy to save on training costs in a department because they can push those costs on to support.
> Part of the issue is that support is never allowed to push back on the customer. They don't get to say "I'm sorry, but you'll have to do a rudimentary computing course before I can proceed further".
I'm sorry, but nontechnical customers are an overwhelming majority. If you can't figure out a way to serve them you aren't going to be very successful.
Because engineers are expensive, engineers that can talk to customers are even more expensive and decent engineers willing to do support are even more expensive.
That said, I do think software devs should be more involved with the customer for other reasons, far to often they are building software without having any idea what the customers workflow is.
"expensive" can be relative. $100/hr but getting to the root of actual problems in, say, 2 days, and saving other customers from having the same issues in the future...
The same reason forcing devs to do ops on their own product justifies having devs do (some of) their own customer support. Otherwise they just toss any old crap over the fence and it becomes somebody elses' problem. Force them to solve those problems and they magically go away, cos devs hate support.
If possible, teams should always "fix it twice" from support requests - get the customer sorted ASAP, and then determine if it's possible to solve the problem fully (either extra support documentation, patch, longer term feature etc...).
At one project we had that pushed over to QA. We didn't have to touch it. Report a problem form sent an email to JIRA allowing us to scrape the influx of 400 daily reports for potential issues. It was pretty helpful in diagnosing a Samsung Android issue where our app was killed for no apparent reason (they have their own additional resource manager that scores apps and kills them UNLESS the app has a persistent notification).
Well, an entire support department that adds no value may indeed cost less, but losing your market because your product is defective (and you don't even know) can not be cheaper.
Given that this is primarily an entrepreneurial site frequented by at least a few people who will build sizable companies in the future...
Maybe it's time that someone laid out a cost benefit analysis regarding offshoring support and presented a good alternative plan.
It's obvious to a lot of us techies, but there's a different perspective that we should be talking to if we want to see industry change for the better.
I'm pretty sure they did. Along with some other services.
In Wrocław (Poland) we have a Google office. From water cooler talk I heard that it's mostly support.
From another source I heard about support calls where one side eventually figured out the accent and suggested moving from English to Polish ;).
Plural for information is valid in Polish and probably other Slavic languages (s. "informacja", p. "informacje"). A lot of Poles do a 1-1 translation when learning and it just sticks in their vocabulary (should work most of the time as Polish has a sizable subset of words with Germanic roots.
Or just hired people (perhaps on H-1B, perhaps not) for whom American English isn't their mother tongue, and who were hired for their technical rather than language skills.
Wow, that's enraging and really bad, even for a company as... unique in its approach to customer support as Google.
I really hope someone on Drive is reading this and can escalate, but it's really bad that it takes a highly voted post on Hacker News to get some kind of resolution. Even "it's too expensive to fix this, here are your files and a refund from when it started breaking" would be infinitely better than this.
The modern, scaled-up, cost-effective way of doing support seems to be:
1) Tell them to restart their PC.
2) Tell them to restart their PC again.
3) Hope they go away, as the amount of revenue they bring simply isn't worth the engineering hours. In your behemoth organization, having an engineer look at a ticket costs around $18000 in internal billing.
4) Wait. Tell them to reinstall the software, and restart their PC.
5) Offer to refund their money. Hope they take the hint, and go away.
6) Wait.
7) Close the ticket with a vague excuse, such as "Missing contact details", or "We've released a new .version since this was opened."
If, and only if, the customer manages to write a blog post funny enough to reach the front page of Reddit/HN/Whatnot, the ticket will be seen by someone in the development organization, not the support organization.
After this, things start to happen. Possibly even someone from VP-level promises to fix bad communication between the support organization, and the development one. They proceed to fix this bad communication by terminating communication completely.
I'm curious to see about the outcome this time.
Usually in such cases the people working for a high-profile company feel embarrassed and intervene personally, the OP thanks them for solving the problem and the case is closed. But this time the level of embarrassment might be too high, and Google folks frequenting HN seem to be mostly programmers. They might just want to keep a low profile for now - tomorrow this post will be forgotten, and the guy will write another post "It's been 192 days..." - just like he's been writing so far and nobody cared.
Ridiculous that they imply throughout that they have a (mysteriously silent) Level 3 support or engineering team working on the issue for almost that entire time.
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?):
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.
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.
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.
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?
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.
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.
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?
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.
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.
> "... 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]? :)
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.
I've found Google Fi to have exceptionally good support, and the same is true with Nexus phones - a very painless RMA process when something didn't work quite right.
the new users of a new, sexy product, usually free, are always in awe because they really go the extra mile and have the best team working on it. that's when everyone else is looking from far away and they see that everything is perfect.
then the team gets promoted, leaves, etc. and what's left is the real Google consumer product. and that is the crap they everyone sees up close. and every problem goes to support forum hell.
Yeah, that might be the case with fi, and it is sort of the natural way of things. I don't remember any older Google products having ever had a good support system, though.
I had three of the Bootloop phones hit me, not only were they not helpful, but the MFG has been a nightmare even with the extension. I ended up migrating lines back to T-Mobile because of the headaches.
Occasionally someone has a good experience with Google support, usually but not always involving one of their latest products when it's still a big corporate focus.
But so far, those good experiences always seem to be rare exceptions. The median customer service experience with google seems to be extremely negative.
If google collected (I don't think they do?) and then published NPS scores for their major customer-facing products, would any of them have positive scores? :)
I had to RMA 3 Nexus 6Ps. I'm not sure if it was bad luck or the 6P just had a bad build quality. The first one the backwards facing mic died causing it to be the world's most expensive text messaging device. The second had a battery issue that caused it to be a brick for about 2 days (this happened over New Years too). The third, bootloop.
The process is relatively painless, with the notable exception being the 2nd time my Nexus shat the bed. It is unreasonable to tell a person "You have to live without a phone for a week." when they rely on UBER/Lyft for work. I had to buy a $100 burner Android. I'm sort of hoping I have a problem with my Pixel. I accidentally chipped the screen at the gym, and it bothers me slightly.
Support from Play has been pretty good. I've used it a few times. I have gotten one person whose English wasn't strong, but they did manage to get me a workable contact. The thing they get right, when they get it right, is that their reps have the authority to solve problems.
I synched about 50GB to google drive and discovered that it started silently eliminating some of my files. The eliminated files weren't found on google dive's bin, but were in my local mac's trash without any matadata or folder info so I couldn't put them back into their original folders. Good thing I had a backup of all these files. Their synch algorithm seems messed up, it also fails to synch every 2 hours on mac.
I've since switched to dropbox, it is worth the extra cost.
The same thing happened to me. Google Drive began silently deleting any duplicate files it found in any of my directories, leaving just one original. A lot of my projects use the same web framework, hence my projects were all broken. Restoring them via their UI wasn't possible either. I stopped using Drive after that.
FWIW, I have a Dropbox for business account and have contacted support several times. Their answers are often scripted and annoyingly devoid of actual helpfulness. I had a problem with Dropbox on Linux forgetting my login/settings. They were no help in solving the issue. I still use and recommend Dropbox, but their "support" has not seemed all that helpful for the power user issues I've needed help with.
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 show that every product has issues.
Despite some occasional competition between 3+ of them, all of the large cloud providers continue to treat 1TB like it's still yuge - and something that only a for-profit enterprise willing to spend hundreds of dollars a year (or more) on storage may encounter.
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.
You're reading a lot more into my statement than what I wrote. I'm talking about Dropbox in particular, not "any company or program that's ever had a security issue".
>Authorization is performed through an agent so the user doesn’t have to trust the application with a password. The agent is the user interface— operating on behalf of the Security Server—used to obtain the user’s password or other form of identification, which also ensures consistency between applications
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.
The problem is unfortunately not as simple as a naive first pass might assume.
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.
At 1 meg, are you not counting storage of the file names and paths?
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.
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.
Windows' notification API gets an overflow (ERROR_NOTIFY_ENUM_DIR) if you change many files quickly, like during a copy/paste in explorer. You then have to re-scan the dir manually.
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.
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.
I'd understand if you don't want to discuss details but for the life of me I cannot understand how the total number of files can affect anything. What function does a sync app do which depends on total number of files? I can just do the sync file by file. It will take 10x more time to sync 100 files than 10 files. But why the brokenness?
- 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.
> 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.
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.
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. 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.
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).
I won't use a Google product if I can avoid it because their support is terrible and automated. At their scale I imagine any customer slight can be rounded off because of the sheer number of customers they have.
I use Google Fi for my phone service, because I can switch my single device and number to another carrier relatively quickly. I recommend my family and friends not use Google Fi, because of Google's reputation for randomly killing off services.
I don't want to have to navigate numerous family and friends to another carrier on short notice, because an executive decided this side-project wasn't quite profitable enough - or because an executive needs this side-project's resources for their own pet project. I don't want my phone carrier shut off because of another company's internal politics, and one way to avoid that is to only utilize services which are a company's primary product.
I was actually waiting for someone to bring up Project Fi, because in my opinion it seems to be one of the Google services that breaks the mold, in fact I've had more than a handful of interactions with their Customer Service and I've always left satisfied or with my problem actually solved.
I really do hope they don't kill it, because I have recommended it to a number of people who have gone ahead and signed up for the service, and they're probably going to remember who recommended it after it goes away...
But at the same time it seems like it should have the be quite profitable, and I have more faith that it won't go away. There's only one service at Google that gets my cash dollars for $80-100/mo, and that's my Fi family plan with three lines.
It can be hard to pay for support. I had to join a waiting list to pay Google for their new cloud support model they advertised a few months back. Hoping they don't kill it off before I can pay them for support to ask why DNS is broke in my GCE environment that I pay for. :(
I won't use any Google product for anything serious because of the complete and utter lack of support. It is virtually impossible to get a human to look at something, even when the process outlined is human-based rather than automated.
1. About 4 years ago, I tried to move a business on Google Maps. It took 10 months and contacting AdWords support to get it done.
2. This year I've been trying to get an API quota increase for my employer. At 3+ months the request has still gone unanswered. Thankfully we don't depend on that for any revenue-generating function.
Looked like there was a lot of support given in this case. Just no solution yet. I wouldn't infer lack of support from this, particularly since the user can still access Drive from the browser.
Looking back, I realize that I had noticed bugs filed months prior. I don't even know what they are about because I subconsciously avoid them. (perhaps out of fear?) Assuming that these are valid tickets (and not outdated), I subconsciously avoided tickets that are months old. Probably because:
1. Bugs that are months old are probably super complicated and will take up a good chunk of time to solve.
2. Since the bug is so old, its not on anybody's priority list. Picking it up just translates to me sacrificing time from my family and hobbies.
3. Even if I go out of my way to sacrifice my time to fix a bug for a customer, there is rarely any gratitude (especially since the issue is months old). Typically, a follow up response would be (rightfully) along these lines: "It took you guys 6 months to fix my problem. Can I get refunded for the past 6 months?"
Knowing how much stress and pain this bug (probably very unique) has caused the author, I will make it a point to always understand old tickets and prioritize it with management to make sure they get resolved promptly.
Is it okay for an engineer to take responsibility for a client and reach out to them directly instead of through an middle man support? Say I was an engineer working on google drive, could anything go wrong if I tweeted author and told him I would personally look into his issue and work with him on it?
> Is it okay for an engineer to take responsibility for a client and reach out to them directly instead of through an middle man support?
The problem with this is that the client now has your direct contact information. If you help them out, then you can bet the next time they have an issue they are coming straight to you rather than going through official channels. If they work at large customer your contact may get passed around within their company and you run the risk of being overwhelmed or having to start directly turning down requests for help. You really don't want to be in that situation.
You can still handle it via the ticketing system so that the user writes to some generated email address, not the direct email address. Would probably have to happen anyway to ensure the conversation is logged properly.
Depends on company culture. I would expect that a Googler would get into some trouble (at the very least step on some toes, though that might be warranted in this situation) if they basically cut out the team this particular bug was triaged to. Probably better to escalate internally and have the engineers actually responsible for fixing the bug have it made a higher priority.
And yet for the customer, it's so much better if the engineer contacts you and tells you they're actually working on your problem. This is why people love dealing with small businesses who don't have those layers of bureaucracy. "Wow, I'm actually talking to someone in a real conversation like a normal human being."
That is part of the trade off between going big and enterprisey versus small and human. I think sometimes it makes sense to go one way, other times it makes sense to go the other.
I work at Google, and get pull requests from people on other teams fairly frequently. It's usually stuff like "I found this particular pattern results in a memory leak, and fixed it Google-wide", but sometimes it's "hey, I used your code, and fixed a bug". It's a bit like how things work in the open source world; it depends on the situation and the individuals, but patches are usually welcome.
The only case where I can imagine someone getting into trouble would be if they spent a ton of time fixing a random bug when they're meant to be working on something else, and it resulted in something important getting held up.
Personal advice: Spend one time 30$ on insync https://www.insynchq.com/ The Google Drive Sync application (which is internally python on Mac and Windows I heard) is horrible and a memory and cpu hog. Insync solved all my problems and with that software I could replace Dropbox.
BTW: Filipino guys engineered that. I'm proud that I have one piece of Filipino software running here :D
That looks really useful! Thanks for telling us about it. Although I have no personal connection to the country, tonight I will raise my beer glass in celebration of Filipino software development. :D
Yes, they should have bought Insync for a good amount of money give Insync for free to everybody. It just works as you said. I also had sync problems with certain file names on the official sync client. Insync just keeps working and I use it for 2 Google Accounts currently (one personal, one gsuite).
In this field, where 90% of one's choices for a product or service are bordering on clones of one another, and the companies involved therefore have nothing to differentiate them beyond how well you perceive them - yes, pretty much.
Why? The service is working as intended. He is able to store things on Google Drive. The issue is with the apps and the fact that he's trying to sync over 700GB via a 32-bit app. Additionally, they're offering him free storage. I understand that it's not ideal, but it's not like the service is down and he's unable to use it at all.
No I'm not. I'm merely pointing out why the app doesn't work. I don't expect the person using it to know that. I'm just arguing that the service itself works perfectly fine so his outrage about being a paying customer is misplaced and misguided. There are several solutions out there to sync with Google Drive. He's paying for the service, not for the syncing app. That is a free product that is available to anyone.
The official Google Drive client has had all sorts of weirdness and missing features. a) 1 account :/ b) Oh, your wifi is off because you just went on a plane? Allow me to _busy loop and drain your entire battery_.
I have reasons for not liking Dropbox much, but their client is a lot more reliable.
Seems like the root cause here is the drive sync app is 32 bit and thus running into the 2GB memory limit. I wonder if it's built with LARGEADDRESSAWARE? Otherwise you could hex edit that into the PE header and get double the usable address space as a possible workaround.
Google has the WORSE support I've ever experienced as a (former) PAYING corporate customer of theirs. I completely distrust ANYTHING they tell me and would NEVER again be caught paying for anything coming from them. Never again.
If you pay for them (i.e. g suite) then you can opt out of the data collection. You either pay with money or with your data; not both (unless you choose to).
I am having issue with my google drive as well, they calculated the wrong storage usage and I simply cannot upload more files. I spent weeks to convince the support it is their bug that clearing cache is not solving the problem. They said they're going to follow up but nothing happened. I then just cancelled the plan, now gmail is complaining not enough space and will stop receiving email. I told the support my situation, and they gave me extra storage for a month while they're dealing with the problem. Though the problem is never resolved, and I now have to send an email to extend that extra storage every month.
Seems like a proper way to get support from big companies in 2017 is to post on hackernews.
> The Windows version of the product currently has difficulty syncing large numbers of files at once due to the memory constraints on 32-bit applications, even if your machine has a lot of memory.
It sounds like they have two issues:
* Access to the existing files
* The money given to Google so far
The first you can probably resolve by using the Linux client to download the files to an external hard drive. (edit) And by "Linux client", I probably mean either "nasty perl script that scrapes the web interface" or "some guy charging $5 for a third-party client" or "a Mac that you borrow from a friend".
The second you can resolve 6 months back by issuing chargebacks. It may be polite to request a refund first, after downloading the files.
Insync that is recommended elsewhere on this thread offer a 15 day trial, then it's 30 USD/GBP/EUR etc. (USD is cheapest of those, but 3200 Yen is even cheaper.)
Get the 15 day trial, make another demand that Google refunds. Use refund to purchase Insync. Or if they don't refund, charge back and don't purchase Insync.
Funny coincidence seeing this here: I just renewed my annual Dynalist Pro subscription today. I didn't realize it's already been a year since I switched from Workflowy!
For anyone who likes Workflowy but is looking for something with more ongoing development, Dynalist is a very nice alternative. And of course you can check out both products for free and see what you prefer.
Update: This seems like a Dynalist day for me. I just got an email from them that their "early bird" pricing for the Pro plan expires on July 15th and the price will go up. So this is a good time to check it out.
(Usual disclosure: no connection with the company other being a happy customer.)
Can anyone with experience explain why companies continue to spend money on "level 1 support"? It seems to universally make the support process worse - so why do it? Is anyone honestly helped by scripted responses that would literally be more effective if handled by bots?
"Bots", although not necessarily the type that people think of today have been handling a lot of work for years. --Generally by providing a link to a possible solution.
L1 support gets anything not handled by bots, and are generally able to close around 80-90% of the cases. That's why you spend money on L1 support first.
L2 handles another 10-15% of the cases, and then depending on the company, L3/L4/developers handle the rest.
Google either has an environment where L3 support doesn't talk to customers (which would be pretty unusual), or they have a huge backlog and just don't have resources to keep up with the cases reaching them. If the latter is the issue, there's not a quick fix - even if you have funding to higher more of them (and they usually earn quite a bit more than L1/L2 support), you have to find people with the necessary skills, or be constantly trying to get people ready to move up (L1 -> L2 -> L3, etc.), which can be difficult if you're dealing with outsourcing on one or more levels, and if the tiers are located in different locations.
The other thing is that if you're one person who has reported the issue and you have an individual subscription, the truth is that it might not make sense for the company to spend as much time that is require to fix your issue - If you're spending $100/year, why should the company spend $10,000 to fix the issue? It sucks, of course, but that's a simple truth about software support.
To oversimplify in a crude way, the idiots who are helped by first line are the people that can't read the support docs and can't write well enough for bots to parse what they need.
Tying up more competent and thus more expensive support agent time just to handle something that a drunk monkey could manage seems at first glance like poor value.
When handled correctly, that first line should make life better for everyone. It should improve availability of competent second life engineers for people that need them.
There is nothing more enraging to me than customer support giving you a reason why they took so long to respond. I do not care that you were on vacation. We are not friends. Pass your work to someone else when you leave.
I had the same issue on my Mac. I solved it by changing the setting of Google Drive from "do a complete sync" to "only sync a few folders". I gradually increased the folders 1-2gb at a time and now the complete drive is synced. Maybe give this a try. Rest i too am a paid user :( and the support you got is a bit dissapointing
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.
The issue is, Google is trying to make serious inroads into enterprise with Cloud/GSuite. This almost certainly costs Google more in reputation among that crowd than it would to fix it or just offer a refund.
This shouldn't happen. There's things called End-of-Life and End-of-Service. EOS usually happens a least a year out. Google should still be servicing previous versions.
My stack is Syncthing and Backblaze. It works very well for many terabytes of data. No huge issues yet, although sometimes Syncthing gets into a weird state about what's been synchronised for a while. Generally a restart of the daemon will fix it.
Backblaze used of course in case all my devices storing synch'd files all fail before I get replacements in place.
It's been six months, eight days, twelve hours
Since you went away
I miss you so much and I don't know what to say
I should be over you
I should know better but it's just not the case
It's been six months, eight days, twelve hours
Since you went away
We tried to standardize on Google Drive, but found that the Mac client frequently (several times per day) would decide that it couldn't connect. Also it would report that it had synched when in fact it hadn't.
There are lots of reasons for us to embrace and advocate the use of ISO8601. Historical records of activity, like this article, demonstrate the obvious one -- it doesn't confuse readers who live in any of the other 195 countries.
CS can be like talking to a wall, the consumer works for the vendor. Squeaking wheel escalates to higher tiers. But sometimes outliers like local sync clients really cannot/will not be fixed -- not enough community out cry ot telemetry.
Sounds like my experience with the old sync client for OneDrive for Business on 32bit Windows 7 box - won't sync, stalls at 82K files. Surprised support did not pass the buck to Microsoft.
6 months on, the solution is to upgrade to Win 10 and start over. Perhaps a solution is try on another platform say a friend's chromebook and rebuild the file structure with manual tedium.
FYI, I've updated the log since this post. Google has refunded me since December and is offering free 1TB for two years. They told me to use Backup and Sync, releasing today, which should solve these problems. I appreciate the refund+free years and have my fingers crossed with the update. I hope they also internalize how broken their support process is, but I'm doubtful.
If B+S doesn't work I'll likely figure out how to sync everything (it's going to be painful, but there are a lot of options in the comment, thanks) and move to a different product.
I've had a problem with Google Drive for a few months now, where they are unable to change the currency I'm paying. Since foreign currency fees are pretty steep and Google Support says they're on it, I've had a friendly reminder that I soon won't be able to use Gmail anymore, and I received some irrelevant BS when asking for a clarification.
From an outsider/user perspective I feel like Google's internal philosophy is more algned with "keeping the algorithm happy" rather than deal with any single customer on an individual basis.
It's been a few months since I tried it, but I managed to get it into a state where it couldn't find a peer on my LAN via autodiscovery.
The Android client can't back up many folders on Android 5+ where Resilio can - I get write/permission errors despite having granted the app Storage permissions.
The Android client is a thin wrapper around the web UI, but doesn't expose all of the options / status messages.
Title is misleading. Their Google Drive application is broken- not web based Drive. So, while they may not be getting the service they paid for, it is somewhat functional; not fully disabled as the title implies.
No, the issue is that the customer cannot use the local Google Drive client. It's right there in the opening: "Google Drive started crashing regularly on PC".
Gmail's default behavior, as anyone who's used it is familiar with, is to automatically upload attachments in excess of a specific filesize to the user's Google Drive account. The user has no control over this.
In addition to how I am pretty sure you can always use the web interface for Drive to upload files (as is the case with Dropbox, at least; remember that the issue here is with the sync client), the person has multiple computers: Google Drive initially wasn't working on one of them... and then it stopped on the other.
It sounds like they attached a document to an email, and as it is over a certain size Gmail includes it as a GDrive link instead of a typical email attachment. The recipient (support) confirmed they were able to view it. It's just a funny aside, and did not impact their case.
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.
I was told - "there's a backlog of support requests. They are old requests that nobody has been working on and our offshore team can't handle. Being an expert in this particular product (and always in need of some extra cash), I said "OK, but let me be very clear that this is secondary to all other work that I'm doing."
Then they proceeded to hand over tickets. I wasn't allowed to communicate directly to customers, and communicating with their offshore staff was a challenge. "I need a log to even begin to troubleshoot this." followed by a frustrated customer reporting "I don't know why you're asking for this log, it won't help." OK, I have to be more clear with support, who I assumed would know. "I need this log. You create it by taking these steps." Another follow up from the customer with the same log again, reporting more frustration. Repeat this process 5 or 6 times, on 20 different tickets. I finally follow up along a different path. "Well, you see they see a request for logs and they only have one template to ask for logs. I'll get it straightened out." A month goes by. I'm getting requests for updates. I follow up on every path I have available. One customer was smart enough to get me the right logs, but they did not forward that log on. After much back and forth I ended up getting that one log. It pointed to a source code problem that I had no access to view, let alone edit. And of course, I have no contact to send this to.
What I ended up doing is submitting a bug report, the proper logs, and a summary of the logic problem in the source through one of my clients support account. Then I updated the tickets that looked to be related with "pending outcome of support ticket 1234. Months later, that particular problem was patched.
Hopefully the customers with their tickets stuck in "level 3 support" were eventually notified. I backed out of that project at some point because it just wasn't a good use of my time.
I understand the need to find a way to scale support. But if you are going to scale, monitor for effectiveness, plan for procedural changes, and do something to make sure the communications channels are working.