Live data from Hacker News

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

dropboxforum.com

301–310 of 429 posts

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

#301
post #195

Seems ludicrous when XFS is the default file system for RHEL.

Yep. Dropbox is going to lose some customers. Maybe it won't be too many (compared to Windows/Mac), but the customers they will lose will be their most technical.

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

#302

It's not encrypted ext4, it's ecryptfs (which acts as a separate layer entirely, creating a virtual encrypted filesystem on top of ext4) - probably doesn't support some inotify feature or some extended attributes that aren't set correctly when used through ecryptfs. If instead you used dmcrypt and encrypted the whole device or partition you'd probably have no issue as it looks just like any other EXT4 FS to the syste…

What do you think are the chances that Dropbox “just works” on a file system on which it isn’t regularly tested but which nominally has the right feature set? I’d go with “not good”. :-)

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

#303

Earlier quoted context omitted.

There's a decent open source sync daemon for OneDrive on Linux - I'm the packager who looks after it on Fedora. With the odd exception when APIs change it just works.

OneDrive doesn't support dotfiles and thus can't sync Git repos.

Onedrive handles Git repos on Windows fine. It does balk sometimes if you feed it large repos, but most often it works fine.

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

#304
post #158

Earlier quoted context omitted.

I'd definitely throw Keybase in there as well. To me it has the easiest experience being cross platform, integrated with the filesystem, end-to-end encrypted, and having solved the identity proof piece.

Keybase is nice, but it isn't a Dropbox replacement. Your files aren't accessible offline; that's kind of a core part of a file sync instead of a file store .

I take your point that they use different mechanisms to provide access to files which are not fully interchangeable. With that said, I think many people probably don't really care or have a need for offline access, since nowadays people almost always have connectivity. Given this I would say in many (maybe most?) instances Keybase could replace Dropbox in practice.

Also, when you consider that being offline for an extended period of time means that your files are not being synced, then the purpose of Dropbox is somewhat defeated. Basically Dropbox can't sync without connectivity and if you have connectivity then you would have access to the Keybase "file store" anyway.

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

#305
post #184

Earlier quoted context omitted.

Your situation is different than mine; this is the first I've heard of Dropbox even registering as a top use of battery. How many files do you have? I've got 26000 files in my Mac's dropbox folder. (Granted, very few of them change more than once or twice a day; maybe 20 or so of those do.)

My top five in the 'Average Energy Impact' column of the Energy tab in Activity Monitor, as of this moment: Docker (3.13) Dropbox (2.08) Outlook (2.03) Safari (2.02) Slack (1.57) Total 131771 files currently on disk (I'm using Selective Sync, because SSD prices)

Interesting. Mine's quite far down on the list at < 1.

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

#306

This is exactly why I stopped using Dropbox and moved everything I have to my own https://nextcloud.com instance. It's very easy to install and upgrade, it is stable, have way more features than Dropbox and you have total control over your own data. Overall a superior experience. If they would do something I don't like, I would just never upgrade anymore and be done with it or just copy the files out of the /data/Nex…

I set up a little Ubuntu Core server with Nextcloud for archives and sharing, and Syncthing for slightly cleverer sync of files I'm actively working with. Syncthing is decentralized, and it's designed so you can just pick any folder and sync it between your devices, which makes for a really handy workflow. But I like good having a long-running server in the middle that I can treat as canonical. That way I have one place for backups, my devices can sync with the server over the Internet when they don't have each other, and I can access Syncthing files via Nextcloud.

I was expecting to still be using Dropbox for a while after that, but it's been surprisingly low maintenance after the initial setup, and it has replaced it perfectly for me :) Highly recommended for anyone bothered by this change.

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

#307
post #293

Earlier quoted context omitted.

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

Because the client can be just as vulnerable to security issues as the server is.

Isolating for security is a totally different topic. We talked about pinning the application to a specific version, and I suggested that it can be done with various tools, isolating from a bigger operating system where packages would automatically updated and Nextcloud would break after a while. It has nothing to do with security.

Of course you can do security for isolation on top of it any time, and sure, you won't get security updates after a while which would be nice, but there are tools to secure an outdated app in other ways either.

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

#308
post #283
post #246

Earlier quoted context omitted.

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.

Nice to hear that my experience was the exception and not the rule! I'm pretty happy with my current solution combining a cheap VPS in the Netherlands for the "I need a server to put some files on" usecase and (encrypted) backups to Backblaze B2, but I'll keep it in mind if I ever need some storage in the US :)

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

#309

Earlier quoted context omitted.

This type of snarky dismissal gets pretty old.

Not as old as someone publishing a blog with the title "This is the year of Desktop Linux". Seriously. No company this large can justify supporting a fringe operating system to their investors and shareholders. In a perfect world they would open source what they did to support it so others could pick up the work and integrate it into other products. Oh well.

Of course my example is essentially irrelevant in isolation. But you do should understand that Dropbox is different than their competitors. Dropbox are the only ones who support Linux. Google Drive, Box, OneDrive etc do not support Linux (random partial featured third party clients do not count.)

In places (eg tech) where there is a Linux user base (eg the developers, devops etc) then Dropbox was the main realistic solution for the whole company. It is now just a random entry in that list, and there is no compelling reason to chose them over the others. Heck Google and Microsoft become the top choices simply because that is where the user accounts, email, calendars and then docs end up.

We don't know just how big this "Linux" group is and it certainly is small (your point). I believe the resulting effect will be larger than Dropbox expected. For example the Windows users I collaborate with do so using Dropbox because I use that for Linux. Dropbox might think they are losing me as one user, but they are also going to lose those Windows users too (they find OneDrive far more convenient as it is already there on Windows and in your Microsoft account).

I'd also argue that in aggregate Linux users are more technical and more likely to be influencers. So again that is more future revenue dropbox won't get, unless they get better than their competitors. Recurring revenue is hurt and helped much in the same way as compound interest works. As you add up the missed revenue over the years, it does get to be a big number. And that money likely went to someone else strengthening them. Remember that Dropbox grew essentially by word of mouth. They are going to lose some of that.

The open source approach would be nice, but I am skeptical. Why would a developer spend their time helping dropbox (the server side won't be open source), and not something completely open? The Linux clients done as 3rd party projects for their competitors seem to be far less complete and reliable compared to the vendor implementation.

TLDR: Dropbox did have a unique selling point in their Linux support. Without it they are indistinguishable from their competitors.

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

#310

Earlier quoted context omitted.

Step 3: $13b company cries over $1000/yr loss of revenue.

This type of snarky dismissal gets pretty old.

What really gets old is seeing:

News headline - "Company removes X feature"

Hacker News comment - "Company is sure to lose customers over this!"

News headline - "Company reports record profits"

If Dropbox really wanted to save some money, they'd fire their accountants and just rely on armchair HN comments to tell them how well their financials are doing.

Post reply on HN