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.
Ending support for Dropbox syncing to drives with certain uncommon file systems
231–240 of 429 posts
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#232Earlier 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…
> 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
#233Earlier 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...
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#234Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#235It'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.
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#236For 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…
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#237Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#238Earlier 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.
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#239TL;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?