Dropbox Brings Back Support for ZFS, XFS, Btrfs and eCryptFS on Linux | Hacker News Reader

Dropbox Brings Back Support for ZFS, XFS, Btrfs and eCryptFS on Linux

linuxuprising.com

272 pointslogix156 comments

That's good news. Happy to see Dropbox thinking about the people who stuck with them from day 1. In the past few years they have been all over the place, trying to find their next big thing and in the process also neglecting their non-enterprise customers. Their core product is still the best in the market and an important alternative to Google.

I feel the same way.

Until recently they seemed to be deprioritizing features I cared about in favor of e.g. Paper, which seems designed for some other type of user. So, when my company was choosing a provider I didn't really have any compelling arguments I could make in favor of Dropbox. Maybe this signals that the tide has turned again.

Exactly, I've always preferred Dropbox because unlike Google Drive, Box, etc they handled files and handled them well. The aesthetics were clean and simple (the new site looks like someone killed an eggplant and based a website on it).

But I've always wondered why they don't expand more on their storage basis for new features? Say email storage and backup (with say an optional web client interface) that supported regular email clients like Thunderbird/Outlook (ok, handwavy magic outlook support). Or a password service that sync'ed via Dropbox (1Passwd was great for a long time this way until I moved to a Linux desktop from a macbook). Their MS Office integrations are actually pretty great. Paper was cute at first, but doesn't build on their storage-first basis by storing say regular markdown files somewhere.

I still think the killer feature that will actually stratify these perfectly similar services will be seamless entire device sync. I have my files clumsily positioned behind my onedrive folder and use shortcuts, but macos insists on the default folder locations for some things.

As clumsy as it is, its still great to be able to grab any devce in the world with an internet connection and access all my files in a few mins. Refining that would change the game for this type of service.

Just in case you've not thought or knew about it, have you tried using folder symlinks on macOS? Might be an answer to those situations where you have to have files in a special folder or its subfolder, but unfortunately will require setup on each device. On Windows there are different folder symlink types available as well (an `mklink` command line program makes them), plus the common things like documents and pictures are actually "collections" where you can add several folders for the Explorer to combine when viewing these collections

Gambled away a lot of the good will they garnered over the course of years. I've moved away and doubt will be back.

Same. I moved when they wanted me to unencrypt my home directory on linux.

I've had good luck with pCloud. In particular, I can exclude file patterns, which has done wonders for my typical workflow (storing lots of code).

Too late. I already moved to a different service and it was a pain.

The only thing that might bring me back is Zero knowledge privacy. There are smaller competitors that have this as a value add, but I'd trust Dropbox more, since Dropbox is a household name.

In case you're wondering what I mean:

"In the context of distributed computer systems, popularly referred to as Cloud-based computing environments, zero knowledge privacy refers to client-server relationships where a server or service is incapable of viewing a client's plain-text data." - cybersecurityforum.com

Which Dropbox competitors are zero knowledge?

Spideroak one. Use them for quite some time... never had any real trouble but I use it more as a backup service tbh. Customer support is pretty good though!

Why would someone downvote this comment? If you don’t like spideroak [1] that’s fine but downvoting for an informative comment seems childish.

1: https://spideroak.com/

Another e2e encrypted storage solution is keybase.io.

Zero knowledge privacy requires a trusted third-party to act as escrow, i.e. to write and distribute the software. Without that, you have no guarantee that the zero knowledge crypto cannot simply be reverted.

I think Megasync supports this too, and you can sync any files/folders on your machine, not having to be limited to just "the Dropbox/OneDrive/... folder".

A few weeks ago I was setting up my new laptop, and I found out that my (free) Dropbox account had gotten downgraded to only be able to sync between 3 devices ... ?!

I have no idea how long they've had this rule, but I'm absolutely certain that I used to sync between more than 3 devices at some time.

I mean, it's kind of Dropbox's thing to be able to do that. Three is also the absolute minimum to make Dropbox Dropbox. If it was two, it'd be a file transfer protocol between two machines. If it was one, it'd be storage.

Sure I'm not a paying customer so I guess they can technically do this ... But to silently downgrade a user's account to what basically amounts to the minimal setting to demo the service, nah that's just shitty. It's just squeezing out my free account to convince me to convert to a paid account.

Which I guess is their right, but the proper decent way to go about that is to make the paid option that much more desirable that you want to convert, not to squeeze out the features of the free users.

Anyone know when this changed? (It could be years, I don't install Dropbox that often)

Middle of March of this year:

https://www.theverge.com/2019/3/14/18265574/dropbox-3-device...

DISCLAIMER: No association with Dropbox.

There's no real justification for outrage over a free product/service. They've paid your cloud storage and associated compute bills, and continue to pay for it, for whatever your usage is - effectively paying you - which should be incentive enough.

VC funded startups have (wrongfully) conditioned users into expecting the moon for $0.

Just flipping the tables a bit - if you ever build your own product/service, wouldn't you want payment for the value it offers to customers?

Fuck em. I've learned my lesson and set up my own nextcloud instance. Couldn't be happier, definitely not going back!

Likewise! Been running the snap version on a $5 DO droplet for half a year now and there's been nothing making me want to go back.

Sure the UX can be improved a bit, but it's been rock solid so far and gets the job done.

Check out the storage servers at time4vps. I have 1TB for about $15/quarter.

That’s about the same as Dropbox — do they offer versioning and minimum retention periods?

It's an OpenVZ virtualized VM. I can run whatever I want on it. I personally do my versioning on my master backup, which has btrfs. Then I ship a copy to the cloud, which is my machine at time4vps.

Yes, my point being that you are comparing a fully-managed service to something which requires you to perform regular operational work. Since the price is the same, that seems like you're effectively valuing your time as free while getting less protection.

I get more. I run services out of the server, like Calibre and pihole.

It's literally half than Dropbox, which costs €10 per month (so €30 per quarter) in its Plus variant. And that's if you pay per year; monthly payment costs €12 per month.

Half as much for half as much storage unless there’s some pricing page adjustments going on.

Nextcloud designer here, thanks for the kind words! What’s something UX-wise that you’d like to see us focus on, or where you have suggestions?

If you’re a designer, we’re also always looking for contributors :) https://nextcloud.com/design/

Dropbox squandered all their initial goodwill & completely lost sight of what made them appealing in the first place.

Plus both my logins seem to be broken now anyway - in different ways. One just straight up refuses my pass manager saved password, the other accepts it then wants a 2FA then proceeds to refuse the password that it initially accepted.

I'll take somewhere else...

That sounds like something is wrong with your password manager (as in _you_ didn't store your url or update your password correctly).

If you're saying Dropbox's password store process has been compromised, this would be a big accusation to make with your single data point.

Can someone explain to me why the choice of filesystem mattered? I would have thought that Dropbox could exist entirely in userspace with FUSE and wouldn't need anything as low-level as direct filesystem stuff.

(I'm speaking out of ignorance both on how Dropbox and filesystems work).

This is a very thorough explanation of why it matters https://danluu.com/deconstruct-files/

Ah, this was a good read. Always eye-opening to see how ignorant I am to a lot of stuff in comp-sci :).

Thanks!

xattrs was their reason, IIRC (even though other filesystems also support xattrs).

ETA:

> A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience. [0]

[0]: https://www.dropboxforum.com/t5/Error-messages/Dropbox-clien...

> The reason cited for this was that "a supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync".

Given that extended attributes are available in most of the filesystems used in Linux today, Dropbox still hasn't answered why they decided to go "ext4-only" for a while.

Probably since desktop Linux users are a tiny fraction of their user base, but create the most headaches and internet outrage.

Relevant discussion: “Linux users were only 0.1% of sales but 20% of crashes and tickets”[1]

I feel like in open source this tends to work itself out with community patches, but with closed source it can become a real pain.

1. https://news.ycombinator.com/item?id=18845205

I think what they may not consider is teams that have a small number of Linux users. In that case, Linux support could be required for the team to use Dropbox, even if the actual number of Linux devices is small.

My point being that the 0.1% of sales might be true per device, but "supporting Linux" might actually bring more revenue than just the devices themselves would indicate because the whole team's revenue would be lost if they didn't support Linux.

Doubtful. I work for a major Dropbox competitor and we don't have any Linux support. We aren't loosing any sales over Linux, nor are we under any pressure for Linux support.

Typically Linux support in products like this is organic: It happens when the engineers themselves use Linux and push upwards to support it.

Anyway, with the amount of testing and verification we do on our product, desktop Linux is impractical. We try to verify on as many possible user configurations as possible. (Multiple Windows versions, 32-bit and 64-bit, Multiple Mac versions, remote desktop, ect). Linux is so heterogeneous that we could only really support it if it was a large customer where we targeted their typical configurations.

> We aren't loosing any sales over Linux

How would you know if you were?

It's shorthand for, "We might be losing sales, but we assume they're a negligible amount of total potential revenue", which is a fair assumption to make.

“We decided to go with <other vendor> because they have Linux support”

“The sales team says that's a requirement for the companies they're talking to”

“Competitor X has Linux support and they're growing faster with no other obvious explanation”

Most customers never contact your sales team in the first place if they see that you do not support their stuff.

This very much depends on the product but note that is exactly why I listed other possibilities. If Linux support was a big opportunity they’d know — maybe not precisely but enough to know it was hurting them.

I’ve been using Linux for around 25 years, some of that selling commercial software and most buying. There’s a very noisy contingent of the community who make a lot of noise but never actually buy anything. You’ll go broke chasing their feature requests because there’s always one more thing before they can switch.

In enterprise sales, there's often a huge disconnect between who you're selling to, and who is actually using the product.

In which context it might actually be perfectly correct to say that you aren't losing any sales over it, even if there are thousands of users who would use Linux support, were it there.

Not sure who you work for, but I'm going to talk about Box since that is the competitor I'm familiar with. I'm in academia and to my annoyance have to interact with Box which has no linux support (and has also deprecated existing workarounds like WebDAV).

It's frustrating to me because academia is a major target for Box, and there are many of us linux users here. I wish the university admins that negotiate these deals would consider us.

It also feels like Box has a dismissive attitude towards us. Linux support has been a much requested feature for a long time, for example see this years-long thread: https://community.box.com/t5/Desktop-and-Mobile-Forum/Status.... IIRC mods encouraged people to vote for this feature request in BoxPulse, where it subsequently became one of the highest-voted features, but then labeled WONTFIX. Also annoying that Box supports linux-based Android, and also supported the less-used Windows phone. Yes there are a lot of linux distros out there, but Box could put out a snap, or just target one distro and let the other distros patch for themselves (like Steam does).

The problem with supporting Linux, for commercial desktop software, is that it's extremely heterogeneous. Some user might be on Ubuntu, another on Redhat, another on Mandrake; all with very different details.

Thus, what happens is that so-and-so runs such-and-such which happens to be incompatible because of some whacky configuration alignment that no one considered.

The test matrix then becomes much more complicated than a traditional test matrix targeting common Windows and Mac configurations.

That's fine for expensive software where the end user might have a very close relationship with the vendor, but for "cheap" software the cost of supporting every possible way someone configured their computer is significantly higher than targeting Windows and Mac.

(Otherwise, the Linux version of a program might cost 2-10x what a Windows or Mac version will cost.)

I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.

If you are targeting businesses, virtually nobody will run Mandrake (which does not exist anymore), Mandriva, Arch, or whatever. When you target Ubuntu LTS and Red Hat Enterprise Linux, you have probably covered most of the enterprise user base.

(Otherwise, the Linux version of a program might cost 2-10x what a Windows or Mac version will cost.)

This surprises me, because Apple changes and breaks a lot of stuff every macOS release and Apple only supports one or two versions back for security updates. In the meanwhile, RHEL only releases every half-decade or so and supports every release for much longer. Ubuntu LTSes are only released every two years and are then more or less frozen as well.

I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.

Except if you care about servers. Or developers for that matter.

The key word is "Desktop"

In an enterprise, even Linux on the desktop is standardized and you’re likely to find that the LTS options (Ubuntu LTS or RHEL) will cover most of the Linux users. And those that aren’t covered are probably used to finding their own way, if given the appropriate tools.

Sure, for everyday end users, supporting Linux can be a pain, but if we’re still talking Enterprise, there are only a few distros that would need to be covered.

Dropbox works on a server. I know companies that picked it because of that.

>I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.

I don't use desktop Linux myself and I'm not usually a desktop Linux advocate at all, but I know that a lot of developers use desktop Linux professionally for good reason. Public administration in Europe is also very gradually moving towards using more Linux on the desktop (in spite of well publicised setbacks). There is a lot of public pressure in that direction.

Desktop Linux may not be important now, but it probably has more growth potential than anything else. And if it grows even just a little bit, the impact on Windows/Mac-only cloud solutions will be disproportionate. It doesn't take a huge percentage of Linux desktops to make Windows/Mac-only cloud solutions very cumbersome.

I think it's a smart move by Dropbox to occupy that niche now, even if it's loss making. There could even be a bit of a moat, because Microsoft and Google both have reasons (Windows/Chrome OS) to drag their feet.

Yes, I have a "free" "unlimited" Box storage via UChicago but I never think to use it since I'm a Linux user and it's such a pain to use from the browser. Supporting Ubuntu and EL would support the vast majority of users on campus.

Is it a reasonable alternative to say linux is supported, but only on specific filesystems?

Here's info on how to build the CLI on linux

https://github.com/box/boxcli/issues/55

Box launched a CLI recently. Not a full client, but it's something

https://developer.box.com/docs/box-cli

I'm sure you don't lose a significant number of sales over Linux. The number of sales could probably be smaller than statistical error, and I think your company made the right decision.

But using 'any' as an universal quantification is false, because some users like me are paying for products like pCloud precisely because they support Linux.

As a Linux and MacOS user I would never recommend a solution that does not work on Linux, unless it's effectively a free complement to something else the company is paying for.

As a Dropbox competitor I know that you've lost at least a couple of sales because with all the companies I worked thus far the only sync solutions used at the company level are Dropbox and Google Drive. And the later is only used because it's attached to Google Suite, but nobody pays for extra storage.

And all the companies I worked with have some Linux users. And I know, correlation is not causation, but I know that at least one of those companies haven't gone with Box because of missing Linux support.

If you haven't noticed lost sales it might be because companies with Linux users aren't even bothering to check you out.

We support Mac. That's rather challenging because Mac users are a minority, yet Mac development tends to be more expensive.

Anyway, with the amount of testing and verification we do on our product, desktop Linux is impractical.

And yet, there are many open source projects have the scale of a file synchronization tool or larger, that manage to work fine (and run a large battery of tests) across different Linux distributions, BSDs, and macOS.

I don't think it is impractical, it is probably just not a good business case.

(I don't necessarily agree, I think Linux users will typically send more fine-grained and useful bug reports and might help you shake out bugs more quickly.)

On the one hand, that might be true, but I doubt that it's true enough in practice. Presuming competent PM's and data analysts, they've likely accounted for individuals vs. teams to begin with.

Even if they haven't and it's literally 0.1% Linux users, I think that it's unlikely a team will pivot on a sale because of a few users who insist on not using ext4. Instead, those Linux users will probably just end up creating ext4 partitions somewhere so everyone can get on with their jobs.

Storage is a commodity like toilet paper. If your preferred brand of toilet paper required you to remodel your bathroom would you do so or buy different toilet paper?

I'm not sure how your analogy works.

1. Dropbox isn't just storage. If it was just storage, it would never have taken off. The reason Dropbox makes tons of money is because it's actually selling a process. Still commoditized, but it's not as lightweight as toilet paper.

2. If you feel like creating an ext4 partition is analogous to remodeling your bathroom, I would question where you choose to hold strong opinions.

I think you have your analogy backwards. I'd happily switch out the toilet paper brand (the file system on one partition) in my bathroom (how my team and I manage shared documents) if that's what it takes to make the bathroom fit its purpose.

Besides, Dropbox didn't kill Linux support, they scaled it down to ext4, which is a perfectly inoffensive choice of file system for an end user.

Zfs has a lot of features over ext4 its not remotely equivalent.

Replacing this functionality on ext4 requires an entire stack of alternatives. Worse if you opt to use zfs and ext 4 you now need 2 complete stacks or to use an inferior set of tools to be compatible with a commodity service.

Yes, this. I often have this same conversation with restaurants who don’t have gluten free options. You certainly aren’t obligated to do so, but if you don’t have any and there is a single person in our dinner group who needs them...our entire group goes elsewhere.

While this is true, I think a more subtle reason to support Linux is the open-source scripts devs setup that may be mission critical.

I work in a bioinformatics lab, and I access Dropbox through the command prompt and do a lot of file cleanup through scripts for dozens of researchers, which is impossible on Windows or Apple.

This BTRFS reversal last year was a nightmare for everyone's research even though I'm the only one who uses Linux.

> which is impossible on [..] Apple.

Out of curiosity, why is that? macOS does provide a Unix environment and Bash & Zsh shells. (and Homebrew or MacPorts are package managers that can provide updated versions of whatever)

Windows, what about PowerShell? I've not used it extensively, but have heard good things.

Or just use Python across all three platforms?

Honestly it's not really feasible to use Python when basic Linux tools like comm, or dos2linux, which take literally just a few characters, recreating the functionality in Python would be a headache.

Yeah, I don' really know hey, I'm just a metal fabricator by trade.

My point was more generally about: surely tools exist on the different operating system to achieve similar outcomes?

I suppose it's possible in the sense that anything is possible. But, in my experience, Mac versions of Linux tools are not A) Posix compliant, B) outdated, C) don't have the exact same functionality, and/or D) Abandoned.

I use Linux because the scripts are easily moved between the cluster computers and my computers, but I suppose YMMV

> But, in my experience, Mac versions of Linux tools are not A) Posix compliant, B) outdated, C) don't have the exact same functionality, and/or D) Abandoned.

You’d definitely want to use Hombrew: you can get the GNU utilities instead of the BSD ones Apple tends to ship, at the latest versions, and it’s a single command to update everything.

Yep, I am not a user of any of these services yet... but if I did go with one it would definitely require linux support and knowing I can trust the company wouldn't screw me. Just because the current sales are low does not mean there's no ability to make good future sales.

Linux users are tech-savy, know how to file bug reports ans help oberproportionally to improve a product.

May be another explanation.

yet another explanation may be the fractured nature of the eco system. Every time I look at linux software bug trackers a good portion is distro related.

This is why the right way to support linux is to solidly support exactly one and only one distro, and then let the rest conform or work around it.

I would beg to differ. There are a lot of people / kids using it that don't really understand what is going on under the hood.

Also the number of bugs that get marked as Won't Fix that are real problems by upstream doesn't help so a lot of people like myself just don't bother after a while and just end up using something else or living with it being broken.

I wish it worked it self out with community patches - more likely is a github mega issue, with people suggesting their forks as solutions if the original maintainer doesn't reply for 24 hours, or during the UTC+8 9am-5pm window.

Multiplatform code when tested tends to show more bugs than single platform code. Also, using different compilers (when it is possible) will help find obscure but real bugs.

In the end this makes the code more robust for all users, not only Linux users.

> Multiplatform code when tested tends to show more bugs than single platform code.

Why would it make the code more robust for users on other platforms if they aren't experiencing those bugs?

Is exposing these bugs worth the extra development time? Surely just compiling with a different compiler is as likely to find bug in the compiler.

I am not saying you are wrong but you are making a lot of assumptions.

This has been my experience as well writing cross-platform software (some of it proprietary in the past).

Because different compilers and different stdlibs do things in subtlety different ways, that may just work on one platform by chance. Memory alignment/layout is often slightly different for example.

Then IO behaviour is often quite different on Linux and OS X despite both being POSIX... (and once you need high performance or Async IO, you're using native APIs anyway).

Memory behaviour is also quite different in terms of buffering, when memory gets freed, etc - e.g. on Linux you often need some malloc_trim(0) calls to actually release recently-free'd memory), on other platforms that's not as necessary, so there are subtleties there.

Different platforms often have different includes as well (on Linux, you generally use GCC's STL/stdlib, on Windows it's a totally different set).

I understand this. Think more along the lines of "If a tree falls down in a forest, does it make any sound if there is nobody there to hear it?". If there is a defect on Linux, but nobody is running it on Linux, is there really a defect?

It's quite possibly a silent bug on the other platforms as well (i.e. relying on undefined or compiler-defined behaviour that just happens to work currently).

A new compiler / OS update / graphics card driver in the future might trip the bug on the platforms it seems to be working fine on currently.

Lets pretend a few things, because I don't think you understand what I am getting at. I have application called "Music Box", I am release version 2.0.0 and it is QA'd before release against Pear OS 7.0.

If Pear OS 8.0 is release a month later and breaks my application because of an API change their end. I would just release 2.0.1 of Music Box that fixes the defects. If I was proactive get hold of a beta or release candidate of Pear OS 8.0 and QA my application on there to see if there was any obvious defects.

The same with a newer compiler or a newer hardware driver. I would just get hold of the beta / release candidate and fix it then. The one thing I wouldn't do is try compiling it on a completely different OS that none of my users use.

Particularly around alignment - it could be that your compiler is emitting instructions that can deal with it, but in a sub-optimal way such that there is a performance penalty. On other platforms, that sort of behavior may cause a compilation failure, or the bugs they cause create bigger (and more noticeable) issues.

If your software crashed it was probably broken to start with you just didn't know it yet.

Tickets showing actual bugs not tech support requests from people that can't read directions are valuable resources.

> Relevant discussion: “Linux users were only 0.1% of sales but 20% of crashes and tickets”[1]

Might be fair to note that these numbers are for a video game, not a file syncing app. Linux is relatively new territory there, let's say when Steam started supporting it.

Don't xattrs behave subtly differently on different filesystems? It makes sense to me to reduce the size of the testing matrix.

It was a stupid and arbitrary decision to begin with. Glad support is back but I don't think I'll be back.

Too late. I have left Dropbox because of their stance on Linux filesystems, price bump with unnecessary features, and the continuous badgering to upgrade to Dropbox business.

It's great change though for those who are still on Dropbox. Their sync is top-notch.

What did you move to? I like Dropbox I just find it crazy that they (or no other company AFAIK) allows me to sync folders on my SD-card on my Android phone.

I would recommend looking into Nextcloud.

though nextcloud definitely is a lot more than: "a folder to sync your files". but hey, apparently even VC in search of growth sometimes notices that their path is not the best.

I did, I found it too clunky for my taste unfortunately

I used Nextcloud/Owncloud in the past, but it's a mediocre product from an engineering perspective. I've found several bugs, the most ridiculous of which was to get a conflict on a file... while using only one client.

Resilio Sync for file sync, with a local NAS and a Hetzner VPN as read-only encrypted peers. SmugMug for sharing photos with family.

Resilio Sync [1]

1. https://www.resilio.com/individuals-sync/

Not parent, but I'm looking into Syncthing (https://github.com/syncthing/syncthing & https://syncthing.net) and they document the issue and known workarounds to sharing from external SD-cards on Android: https://github.com/syncthing/syncthing-android/wiki/Frequent...

syncthing is a great choice, I've been happily using it for 2 or 3 years across Linux, Android, and Windows. I've never had to do anything special to use an SD card on Android.

> I've never had to do anything special to use an SD card on Android.

It appears newer versions of Android do not provide a way for apps to access _external_ storage using ordinary POSIX APIs. SD cards can be used to back and provide "internal storage" on Android, and I don't think that is a problem (yet).

Google basically made it impossible for file syncing software to work on SD cards in modern versions of Android (IIRC since Marshmallow or maybe Nougat) unless you use the 'SD as internal storage' option which many manufacturers have disabled entirely.

> Their sync is top-notch.

Which is exactly what prevented me from switching even though I run Linux. I've tried other file synchronization products and the speed was always significantly lower.

Today I synced 29000 files (44gb) from home to work with Nextcloud in less than 30 minutes.

I think that’s not only more than acceptable, but at least 10x the performance I’d get from Dropbox.

Yep. I removed them from my life after the 3 device limit and will.nit fo back. I will give a few bucks to Apple, Google and Microsoft for their file services for a while as I decide which one I like best.

I'm also a Dropbox on Linux user, are there other cloud storage services with better Linux client support? I was considering Google Drive but it doesn't seem to support Linux at all.

GVFS (https://wiki.gnome.org/Projects/gvfs/backends) now provides a package that lets you log in to your Google Drive account and access it from Nautilus, but you have to be on GNOME for it.

This is very cool and I use it from time to time, but it's not actually keeping anything synced afaik (it's equivalent to the web ui, but very nicely integrated in gnome).

And KDE has kio-gdrive for the same thing with Dolphin.

MEGA, Seafile, NextCloud, pcloud

I'm using Google drive with insync which is really good but not free.

https://github.com/astrada/google-drive-ocamlfuse is also a good alternative if you're happy with mounting your google drive folder. Gnome now also has pretty well working support for this built in.

Many people recommend Insync and while it may be good enough for people stuck with Google Drive on Linux, it doesn't match Dropbox's sync.

In my experience with Insync it crashes a lot and it's very slow compared with Dropbox. And of course they have GDrive's limitations, for example the inability to do block-level sync.

Recommending third party solutions is fine, but can you manage a 300 GB archive of files with them? And can you trust those solutions to not corrupt your data?

I know I wouldn't because I have a hard time trusting the official clients of GDrive or OneDrive after noticing them actually corrupting my data, so no thanks.

> In my experience with Insync it crashes a lot and it's very slow compared with Dropbox.

As a counter-datapoint, it has never crashed for me and is faster than Dropbox. Though I don't have 300GB files (might explain your crashes and speed issues).

"are there other cloud storage services with better Linux client support?"

My habit, of course, is to gently remind the reader of the existence of rsync.net[1][2][3] which, I hope, is the service that perfectly matches your unix/linux use-cases.

But in this comment thread, and to my parent specifically: I am genuinely curious - have you not ever heard of our service ? Very interested to learn this ...

[1] https://www.rsync.net/platform.html

[2] https://www.rsync.net/resources/howto/remote_commands.html

[3] https://www.rsync.net/resources/howto/unix.html

Have not heard of rsync.net but I’ll check it out

Edit: the platform link is lacking a right margin on mobile, and the landing page’s hero image resizes the page when the URL bar appears/hides, at least on iOS

Looks like your prices have come down, but I still get a better price running my own 1TB storage server.

"have you not ever heard of our service?"

No I hadn't heard of rsync.net before. I even browsed a few 'listicles' and didn't come across it. I admit even if I had, I'd tend to lean towards more established clouds. But I'll certainly take a peek now since it seems to fit my bill. Thanks for the reminder.

"I admit even if I had, I'd tend to lean towards more established clouds."

Early winter of this year will mark 18 years that we've been providing cloud storage ... although it wasn't called cloud storage until we created the "rsync.net" corporate entity in 2005 ...

We'll be around if you decide to check us out :)

I switched to Zoho Docs since I needed to sync across my Windows & Linux laptops (with ecryptfs on Ubuntu).

Their Linux client is great so far in my experience, considering I use it exclusively with Cryptomator (which syncs a lot more individual files).

I dropped Dropbox on Linux for (of all irony) OneDrive and am working through configuring the client that’s on Github.

I dropped Dropbox for the combination of OneDrive and Syncthing just yesterday. Doubt I'll go back. Dropbox can't be trusted anymore.

I also went with OneDrive--mostly because I hadn't realized how substantially superior OneDrive has become compared to Dropbox on Windows (particularly with selective sync).

I’m using syncthing for file sync, and testing out spideroak for backup (plus just a hard drive locally). I like the idea of spideroak because it’s e2e encrypted, or so I understand, and syncthing has just worked decently well the last few years.

I tried sparkleshare once but it only syncs to Linux, and you have to set up a sync server

Still rely on Dropbox for file sharing with others though (however, Firefox send is an alternative now)

Do you need it to be a commercial service? I just use nfs over wireguard, hosted at home on some old hardware I already had. Total cost: $0 Setup took no more than a few minutes.

Obviously that's not suitable for everybody for a number of reasons, but for me it's totally erased the appeal dropbox or anything like it.

I've had good luck with pCloud on linux. And you can exclude file patterns, which has been a big improvement for storing my code (ignore all node_modules directories).

Same. Inertia kept me with Dropbox all these years. It was easier to pay them than to figure out how to operate the alternatives. I'm not going to get those hours I spent migrating back--it's sunk cost now.

> Their sync is top-notch.

Not really, occasional merge conflicts are par for the course with Dropbox. Never seen one after switching to Google drive with Insync. Dropbox is very inflexible, for example doesn't even let you choose your own folder name, doesn't work well when syncing across case-sensitive (Linux) and case-insensitive (Windows) file systems. It was a sucky experience overall. I am relieved I don't have to use it at work anymore.

https://forums.insynchq.com/t/no-warning-when-file-conflicts... ? Seems very dangerous for keeping data safe.

And for what it's worth I've heard that google drive by itself often does the same thing.

And now Dropbox runs a background web server so they can serve their web-based UI, at least on Windows. I can’t believe how none of these huge companies that burn through cash like there is no tomorrow can’t afford to pay an intern to write an easy-to-maintain native UI for these simple “dashboard” applications. Ugh.

What makes you think an intern would be able to do this? A few of them might, but I imagine most wouldn't. Being able to make something easy to maintain means knowing what is difficult to maintain. Except for the sharpest, who actively learn from others, the best teacher is experience.

I fully intended that as hyperbole, but the idea was "use ready-to-use native widgets/controls to represent options/state" with as little "custom" UX as possible. The user-visible Dropbox UI is nothing more than a preferences dialog, the real "app" can be written by experts with 30 years of service and systems software expertise under their belts: it runs as an invisible background service using APIs for which well-supported cross-platform abstractions are readily available for all non-interpreted (and most interpreted) languages (inotify, channels, network io, encryption, compression, database serialization, etc).

The preferences and configuration panel is not what anyone thinks of when you say "Dropbox" and does not need to be "let's use css/html to create a custom UI that does not conform to the system ux guidelines so we can shove our branding down users' throats," in turn necessitating "now we need to use a full-blown browser engine to render the UI and an always-running standalone web server to interface with the background service to get backup status and information."

I've been using Dropbox since its first public (beta?) release on multiple different platforms, both supported and unsupported. I uninstalled the application three or four days ago when I found that background process lurking on my PC (in addition to the other background Dropbox processes which I did expect to see). If their application is turning into a web app, I can already use my main browser for that.

What a mess. Product mistakes like this generally show that the company is either desperate, or unaware of their customers. I use xfs on Arch, and dumped Dropbox for Google Drive (with Insync) the second they made this announcement. It would be a pain to migrate back, so I won't.

I use Arch too, with BTRFS, but made a mounted sparse file for Dropbox, which has been an utter nightmare setting up on all my computers. I'm tempted to just keep it in case they reverse course again.

> What a mess. Product mistakes like this generally show that the company is either desperate, or unaware of their customers.

They were very much aware of their customers. They just didn’t care.

They intentionally decided to break working customer-setups, thinking it was somehow “ok” just because they got a heads-up warning.

Completely disrespectful. I left for Nextcloud, and I’m not coming back.

After fighting with Box for a bit today I'm really happy that Dropbox still exists.

What issues did you have with Box? I was considering trying them

Why would users of those file systems trust Dropbox not to just remove support again?

It would be a bit absurd to remove support in the near future. It would make them seem very flaky.

I'd say they got their money's worth the first time, what with the facially obvious false explanation

Syncthing is open source and works great - windows, osx, linux, etc...

But not iOS.

So for me that means Nextcloud. And that works pretty great too!

I can't tell you how much it pains me that syncthing doesn't support iOS. I would donate money to a project that added iOS syncthing support.

I've used ios fsync() for some time.

Doesn't show up in the iStore for me.

I realize there’s a lot of speculation happening here, but as a long time (since beta) user who was not looking forward to moving because of the plummeting Linux support...Thank You.

Also too late here. As a big fan I was bummed to be forced to leave the free plan. This and the 3 device limit were a deal breaker. Now I'm onto syncthing and keybase FS.

To compensate for supporting more filesystems on Linux, they are now switching to a file manager-like application instead of the unobtrusive just-sync current option:

https://arstechnica.com/gadgets/2019/07/dropbox-silently-ins...

Luckily they haven't ported it to Linux yet :)

"Due to an error, some users were accidentally exposed to the new app for a short period of time."

Interesting. I absolutely love DB sync on Linux, but I cleared my data yesterday. I got tired of dealing with the ecryptfs situation and couldn't go all in on DB because of the 2TB cap. I ended up going with Amazon Drive plus ExpanDrive for now.

I really hope this means they will add support for SmartSync on Linux.

That is the one new killer feature. Paper and the rest are not interesting to me.

Oh, and they need to turn on full text searching inside files for paid Dropbox Plus accounts. That is a ridiculous crippling.

I wouldn't go back even if they brought back the public folder.

Seems to be working just fine on the eCryptFS setup I have on an older laptop (which I stopped using a few months back). All we need now are ARM versions of the client.

Why not supporting EL7? Is it that demanding? I am running dropbox on a docker container full of hacks and tweaks...

Meh, I've already moved on to other tools.

OK now I can go back from MEGA

Why is Dropbox better for you than MEGA?

it's only the paranoia in me of a New Zealand company founded by a guy much resembling John Mcafee in madness vs a publicly traded USA comp

Reply on news.ycombinator.com