161–170 of 238 posts
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
Curious as to what you think it needs? I've found it perfectly adequate for my purposes, and fairly intuitive to set up.
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. I should…
Still looking for something I can use like AirDrop but MacWindows
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…
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://…
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...
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…
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.
The fact they haven't refunded him yet is quite disturbing
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.
Earlier quoted context omitted.
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.
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…
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://…
How can you write that with a straight face when the 32-bit client is in fact the only client?
Earlier quoted context omitted.
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 squ…
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.