Ending support for Dropbox syncing to drives with certain uncommon file systems • Hacker News Board

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#281

Post by fanzhang » Fri, Aug 10, 2018, 4:33 PM UTC

Walkman wrote: post #276

redm wrote: post #272

Earlier quoted context omitted.

"If they would do something I don't like, I would just never upgrade anymore and be done with it." -- That sounds like a good strategy but in my experience, it never works because your technology environment is not a vacuum (I assume). At some point you'll need an upgrade for security, compatibility, etc.

It can run in a container, a virtual machine, hosted on a cloud instance or whatever. Nowadays, you have infinite choices for isolation. One of my colleague runs it in a DigitalOcean droplet and nothing else.

If you want to run your file sync client in a container, I think that limitation alone removes a huge amount of value from a low-friction file sync tool.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#282

Post by snerbles » Fri, Aug 10, 2018, 4:33 PM UTC

acdha wrote: post #263

snerbles wrote: post #162

Earlier quoted context omitted.

No. There's already a peer-to-peer relay infrastructure in place for when your devices can't make direct connections to each other.

That sounds like the answer is actually yes because you have to run the various computers, provision enough storage to hold everything, secure them, and make sure you have a backup plan.

> run the various computers

That's a vague assertion that can apply to anything.

> provision enough storage to hold everything

Syncthing can ignore directories/patterns at the local level.

> secure them

And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices.

> have a backup plan

Another non-sequitur. Either tool can be part of a backup solution.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#283

Post by rsync » Fri, Aug 10, 2018, 4:34 PM UTC

znelis wrote: post #246

justinclift wrote: post #128

Earlier quoted context omitted.

rsync.net seems to get mentioned around here every now and again. I haven't used them though personally, so not sure of good/bad/etc. Unlike what their name (rsync) suggests, they do seem to support Windows clients and aren't *nix only: https://www.rsync.net/resources/howto/windows.html

I had a pretty underwhelming experience with rsync.net and their cheaper version without snapshots a year ago. Speeds where initially 1MB/s on a gigabit connection between Sweden and their Switzerland location. After complaining they exempted me from traffic shaping and I got 2-4MB/s instead.

I know who you are and I am sorry to hear about this (again).

This is a weird, known issue that somehow keeps cropping up on our init7 network connection specifically to scandinavian countries.

I'm sorry we couldn't resolve it.

If you can stand your data being in the United States, our Denver location has a 10gb he.net fiber connection which is God's own Internet. Recommended.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#284

Post by Walkman » Fri, Aug 10, 2018, 4:37 PM UTC

fanzhang wrote: post #281

Walkman wrote: post #276

Earlier quoted context omitted.

It can run in a container, a virtual machine, hosted on a cloud instance or whatever. Nowadays, you have infinite choices for isolation. One of my colleague runs it in a DigitalOcean droplet and nothing else.

If you want to run your file sync client in a container, I think that limitation alone removes a huge amount of value from a low-friction file sync tool.

Why would you run the client in a container? I was talking about the server.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#285

Post by rsync » Fri, Aug 10, 2018, 4:37 PM UTC

lreeves wrote: post #176

justinclift wrote: post #128

Earlier quoted context omitted.

rsync.net seems to get mentioned around here every now and again. I haven't used them though personally, so not sure of good/bad/etc. Unlike what their name (rsync) suggests, they do seem to support Windows clients and aren't *nix only: https://www.rsync.net/resources/howto/windows.html

The documentation for the Windows client (1) almost seems like a joke. In the screenshots the text gets cut off in the UI, there's sentences that say "don't use this versioning feature we're about to talk about" and tons of text that's been striked-through. There's also zero mention if the client supports backing up open files via volume shadow snapshots which is basically requirement number one for any Windows backu…

We're really all about the direct unix to unix connection.

The point of rsync.net is that you can log onto any unix system, anywhere, and interact with your cloud storage - with no software installation or configuration necessary.

The Windows Backup Agent works very well and has recently been updated but the documentation you are seeing reflects the fact that it is a secondary function here at rsync.net that is mostly provided for the convenience of customers in mixed environments.

We are not a dropbox alternative.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#286

Post by thesephist » Fri, Aug 10, 2018, 4:38 PM UTC

owaislone wrote: post #223

eloff wrote: post #214

Earlier quoted context omitted.

I get a terabyte free with onedrive, because of the office subscription. I wish I had a good way to utilize it on Linux.

Out of curiosity, what happens if you office subscription ends? Obviously you won't be able to sync but does onedrive have some sort of grace period to let you download your stuff and at what point would it go and completely delete your data?

I believe the modus operandi for most personal cloud storage providers here is to make the entire dataset read- and delete-only until the user gets enough storage space (by upgrading or deleting files) to be able to write/upload again. That, plus some incessant push messages to your client devices about upgrading, which is annoying but expected.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#287

Post by Shish2k » Fri, Aug 10, 2018, 4:38 PM UTC

acdha wrote: post #263

snerbles wrote: post #162

Earlier quoted context omitted.

No. There's already a peer-to-peer relay infrastructure in place for when your devices can't make direct connections to each other.

That sounds like the answer is actually yes because you have to run the various computers, provision enough storage to hold everything, secure them, and make sure you have a backup plan.

> run the various computers

Are you saying dropbox works without computers O_o?

> provision enough storage to hold everything

It's true that on all your clients put together, you need enough space to have one copy of your data; where for dropbox you can have one single sparse checkout and let their servers hold the full data set. I've never seen that be an issue in practice though - on the contrary, my laptops have enough space to hold all my data, and my dropbox account doesn't, which is why I went to syncthing in the first place.

> secure them

What security do you need to add to syncthing that you don't need for dropbox?

> make sure you have a backup plan

I guess dropbox counts as having offsite backup implicitly; personally I'm using syncthing between a few laptops and desktops in different locations and counting that as the off-site backup plan.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#288

Post by fencepost » Fri, Aug 10, 2018, 4:40 PM UTC

owaislone wrote: post #223

eloff wrote: post #214

Earlier quoted context omitted.

I get a terabyte free with onedrive, because of the office subscription. I wish I had a good way to utilize it on Linux.

Out of curiosity, what happens if you office subscription ends? Obviously you won't be able to sync but does onedrive have some sort of grace period to let you download your stuff and at what point would it go and completely delete your data?

If it's the business version, you have full access for 30 days, admins have access for 90 days, then it's deprovisioned (source: https://support.office.com/en-us/article/What-happens-to-my-...)

On the O365 Personal/Home or direct OneDrive plans, it looks like your data remains available but read-only for 3 months, then your account is "frozen." You can do a one-time 30-day "unfreeze" to get access to download/delete (to get under your quota), then it gets "frozen" again. Eventually it'll be deleted, but I don't see documentation for how long that takes. (source: https://support.office.com/en-us/article/what-does-it-mean-w... linked from https://support.office.com/en-us/article/OneDrive-storage-pl...)

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#289

Post by 8077628 » Fri, Aug 10, 2018, 4:40 PM UTC

This is a tragic decision on Dropbox's part. The service's popularity is a product of it being stable and running everywhere. If they start pulling back compatibility, where does it end? Even if this change only impacts a small percentage of users, it threatens everyone that their compatibility may be revoked.

Dropbox is violating their philosophy as a universal solution and squandering their key selling point for some small cost savings. What a horrible decision.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#290

Post by Aaargh20318 » Fri, Aug 10, 2018, 4:41 PM UTC

scott_s wrote: post #96

vxNsr wrote: post #68

Earlier quoted context omitted.

Yeah, this is probably about cutting out the big data users. They don't even offer an unlimited plan, but they probably noticed that certain linux users were using most of their 2tb plans while everyone else wasn't. Lose the most active users, keep the ones paying for something they don't need.

Are you and XorNot guessing, or are you basing this off a statement they made? Because the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems. That complicates development quite a bit (because you need to have developers who know the quirks of the file systems) and testing a lot (because all changes have to be tested on all variants, and it becomes multip…

> the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems.

But they don't have to maintain a bunch of different filesystems. That's the OS's job. From the application's PoV there shouldn't be any difference between these filesystems, all they need to do is check if the required feature (xattrs) is enabled for a certain FS and that's all.