Live data from Hacker News

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

dropboxforum.com

231–240 of 429 posts

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

#231
post #39

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…

Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.

On the contrary, Ubuntu 18.04 dropped the home directory encryption entirely and now only supports full disk encryption.

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

#232

Earlier quoted context omitted.

I’m not talking about FTP, which isn’t a network file system. I’m talking about NFS, AFS, and sucessors in that line of development. E.g. https://www.slideshare.net/mobile/snehcp/coda-file-system . I’m literally talking about the theory of the paper by Richard Gabriel ( https://www.dreamsongs.com/RiseOfWorseIsBetter.html ) which is that worse solutions often win because it takes too much time to bring a good solution…

I think you mixed up worse is better. The idea behind the phrase is that quality does not increase with functionality. Functionality often means features along with bells and whistles. Sure that application looks pretty and offers tons of features but with that complexity and glut comes a steeper learning curve as well as possible security and stability issues in the code (more bugs). A good comparison would be compa…

I'm talking about these two points from the paper, regarding the "Worse is Better" philosophy:

> Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

> Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct.

Dropbox is simple in implementation, at the cost of simplicity in the interface and correctness. E.g. it is simpler to simply punt on locked files in Windows. Tell the user to quit Word if they want their file to sync, instead of handling file locking at the protocol level. Likewise, it's simpler to detect changed files after the fact than write a filesystem driver to knows what blocks are changed. But it degrades the user experience (their computer burns clock cycles re-figuring-out information a real filesystem driver would've had).

The upside of all that is that Dropbox was simple to implement, simple to port, and simple to deploy, which made it popular:

> Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.

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

#233
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.

Use a flow to replicate your onedrive in Azure Files, then mount it to your Linux box: https://flow.microsoft.com/en-us/galleries/public/templates/... AND https://docs.microsoft.com/en-us/azure/storage/files/storage...

That would be very much not free

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

#235
post #39

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…

Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.

I use Google drive, but the Linux support was awful and I started using insync. It's about $25 for a lifetime license and I love it. I run Ubuntu with encrypted home and have for years. It works great and I highly recommend it, and I don't work there, just a happy user. The Nautilus integration is decent too.

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

#236

For those interested in open source alternatives, syncthing, NextCloud (fork of ownCloud), and Seafile are some of the big names in this space, as others have mentioned. Personally I'm on syncthing. It's one of the best pieces of software I've ever used. My only complaint is it's not really instantaneous for me. In theory it works with inotify, but I've never quite been able to get it to work. I'm confident it will e…

I used to use ownCloud. Just curious - why is it not in your list of alternatives? Did the project die?

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

#238
post #140
post #39

Earlier quoted context omitted.

Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.

If you feel comfortable with Google, Gdrive has a great client in the form of OverGrive.

And there’s always rclone. Combine that with whatever encryption you want and you’re set.

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

#239
post #154

TL;DR: Dropbox tells with a very unhelpful popup: "Move Dropbox location - Dropbox will stop syncing in November" . And on the forums, dropboxer Jay precises that starting Nov. 7, 2018, they're limiting support to Windows / NTFS, macOS / HFS+ & APFS, linux/Ext4. They say missing X-attrs support is what guides dropping other fs. They didn't answer yet if displaying this message to users of common-through-Ubuntu Ext4+e…

Missing xattrs? What?

See original message from Dropbox support: https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dr...

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

#240
post #221

Earlier quoted context omitted.

Step 2: use the 20% developer manpower required to support filesystems used by 2% of the userbase to instead better support the other 98%.

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

This type of snarky dismissal gets pretty old.
Post reply on HN