It's been 191 days since Google Drive worked for me
dynalist.io
dynalist.io
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.
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.
We would be needing further informations
It sounds uncannily as if Google has offshored service on Google Drive.
what's next? wondering if they have left you tube ui to chance?
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.
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.
There's the (probably apocryphal) story of WordPerfect (huh, what's that?) support. It ends with:
SERVICE: "Tell them you're too fucking stupid to own a computer."
http://www.generationterrorists.com/quotes/misc/wordperfect_...
Well, no kidding, because who would pay for that?
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.
https://www.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...
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.
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?):
> 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.
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.
AKA don't have the courage to do it.
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.
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.
If someone was complaining that an Amazon S3 application was broken, that would be a different story.
Note that even you said "service" in your description of what it is.
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.
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.
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.
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.
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.
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.
If the client allows you do do something, and you do it, and it causes the client to break, that is 100% a "failure"
> 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).
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.
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.
Also why can't the support tell him that directly, instead of the endless vague explanations.
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!
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...
How can you write that with a straight face when the 32-bit client is in fact the only client?
There is extensive evidence (of which this is just the latest element) that this is not a good idea, and won't be until there's a fundamental change.
Empowering support to be able to task engineering resources? Blasphemy!
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.
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.
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? :)
Spend the $10/month. Don't go on for more than half a year with your storage being broken.
Disclaimer: no affiliation except a satisfied pro account user
EDIT: Edge cases notwithstanding.
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.
My attempt was circa mid-2016.
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.
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.
Dropbox themselves state this on their websites:
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.
I've done some comparisons across various companies sync clients, and it is a tricky problem.
(Disclaimer: I work for Google).
2. Read list of files present locally and write to file B
3. Sort files A & B
4. Read files A & B to update remote and local files
This can be done with less than a meg a memory.
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.
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.
One example of related issues: https://github.com/libuv/libuv/issues/626
(I've been very slowly designing my own, and the first thing for me was coming up with a list of awkward cases ..)
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.
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.
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.
for example: http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...
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.
No, thank you.
- 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.
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.
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.
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.
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....
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.
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.
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.
What possible reasons could there be for your support team denying the refund that may have been left off that page? Hypothetically speaking.
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.
What possible information would you need? You are basically saying you don't trust OP's account of what happened.
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.
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'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?
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 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 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.
Would be awesome if their free products came with support, but I know that's asking too much.
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.
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?
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.
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.
BTW: Filipino guys engineered that. I'm proud that I have one piece of Filipino software running here :D
Do you really have to publicly shame a company into action?
You make it sound like some kind of fundamental truth of computing that it would break.
The sync process is ~1 file at a time. It doesn't need to keep the entire database in (virtual) memory.
(Note: Dont do this, it pisses Google off and you will lose all your files)
I have reasons for not liking Dropbox much, but their client is a lot more reliable.
https://support.google.com/drive/forum/AAAAOxCWsTomo298Ko1vU...
> Google Drive Error D41D "Unspecified Error" when trying to upload/sync large amount of files (700GB/1.2 Million files)
Support actually looks decent per this post. Just no solution yet. But that's different, since the product still works for this user via the web.
Seems like a proper way to get support from big companies in 2017 is to post on hackernews.
Or you can reach out to me (details in profile).
(Disclaimer: I work for Google, but comments here are my own).
I don't know if you've removed them since posting this, but your contact details aren't actually in your profile.
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.
> > Now GDrive is crashing consistently on my Mac.
> The second you can resolve 6 months back by issuing chargebacks. It may be polite to request a refund first, after downloading the files.
Seconding this; I've successfully gotten chargebacks in much less extreme cases.
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.
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.)
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.
As long as the business is growing, nobody cares which outcome happens.
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.
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.
Go download synchthing and be done with it.
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.
Amazon silently failed to upload some files.
We went back to Dropbox.
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.
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 do a side by side comparison.
Still looking for something I can use like AirDrop but Mac<->Windows
I have tried a lot of services, and in the end, Dropbox is just bulletproof on Linux and Windows.
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.