Hacker News Reader

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.

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.

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"

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.

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.

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.