Earlier quoted context omitted.
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 s…
Ending support for Dropbox syncing to drives with certain uncommon file systems
311–320 of 429 posts
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#312For 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?
Long term I do still plan on moving to NextCloud, the core dev team from owncloud moved over and I've always been happy with OC, but I need the time to actually figure out why I'm getting sync errors with the suggested setup after following all the suggested fixes.
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#313Earlier quoted context omitted.
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 e…
I'm saying that Dropbox does not require you to run every computer yourself. If your house burns, floods, gets burgled, etc. not losing every copy is a really nice benefit for the average person. Not needing to make sure that their laptop is running at the same time as a desktop computer is similarly nice for being able to depend on having n > 1 copies.
> > 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.
It definitely depends on the user and is less of a problem as SSDs get larger but I definitely know people who had things like large photo/video libraries which they didn't want to have taking up 80% of storage on every computer they own.
> > secure them > > What security do you need to add to syncthing that you don't need for dropbox?
Two aspects: one is relatively low-impact but still worth making sure you're comfortable with any risk of data loss. If you use FDE on your phone / laptop but someone steals the desktop which has all of your synced data on it, is that a problem? Do you forensically wipe drives before getting rid of them? Dropbox's data is encrypted at rest and since they're hosted in a proper data center you don't have to worry about someone stealing a copy as easily as breaking into someone's apartment.
The other is more important now that ransomware is an industry: if you get malware, how robust are your recovery options? Simple versioning doesn't help if, say, the malware touches a file multiple times or if the versioning system wasn't designed to handle malice and so e.g. an attacker can just empty the trash or overwrite the old versions too.
One nice thing about the hosted model is that it has a completely different trust chain so even if you're totally compromised it doesn't allow them infrastructure-level access. That's far from perfect but enough people have recovered deleted Gmail messages, Dropbox files, etc. that it's worth asking whether you're comfortable about your data recovery options in any comparison.
> > 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.
That probably works for most scenarios other than a bad security compromise but how frequently do you verify those copies? Does syncthing have checksums to ensure that the copy you think you have hasn't been corrupted?
Again, I'm not saying that syncthing is a bad choice, only that “It works better” is a very broad claim which is clearly not true as a general statement. Convenience and reliability have significant value to most people.
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#314Earlier quoted context omitted.
Does ZFS gaining steam on Linux in recent years have anything to do with the state of btrfs?
Does it really gain steam? Last time I checked the CDDL license incompatibility with GPL made it impossible to ship ZFS with Linux, and as such, distros have separate packages not maintained by the core team (I'm thinking of Arch right now). For the record I would be very glad if I could seamlessy use ZFS, but from my perspective it looks like a lot of work that can break in unexpected places.
I used these instructions:
https://nixos.wiki/wiki/NixOS_on_ZFS
Ironically, I felt less of a need to use ZFS on NixOS. I don't have a large pool and snapshotting the system is not really necessary, since in NixOS you can always roll back to a non-GCed previous version on your system. But I use filesystem compression and might use snapshots on /home.
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#315It'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
#316Excluding XFS is an odd choice as it's very common in the server world. I'm assuming encryptfs-ext4 has some attribute issue that prevents them for doing efficient deltas. That aside, what's the use case for encryptfs at all? Isn't it strictly worse than LUKS on the underlying volume or a volume file mounted via loopback?
I would hold my horses on xfs being unsupported claim. They explicitly said any modern file system with xattr is supported. XFS does fit that description. OP has drawn his own conclusions from the Dropbox reply.
>The supported file systems are NTFS for Windows, HFS+ or APFS for Mac, and Ext4 for Linux.
>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. (emphasis mine)[1]
XFS may support xattrs but that doesn't mean that Dropbox officially supports it. They are pretty clear on ext4 being the only supported filesystem.
[1]https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dr...
Edit: added link to the proper comment in the Dropbox thread
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#317Earlier 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.
What issues have you found with this Onedrive client[1]? I've been using it for over a year without any hiccups beyond the odd duplicate file [1] https://skilion.github.io/onedrive/
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#318Earlier quoted context omitted.
On the contrary, Ubuntu 18.04 dropped the home directory encryption entirely and now only supports full disk encryption.
Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base... > "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."
https://defuse.ca/audits/ecryptfs.htm
The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#319It'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…
The backing files for your ecryptfs will still get synced though, correct?
Re: Ending support for Dropbox syncing to drives with certain uncommon file systems
#320Earlier quoted context omitted.
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 ex…
Yeah, no, I don't think so. If my bus or train goes through a tunnel, losing my dotfiles or my OneNote notebooks or whatever else is pretty bad.
Forget first world problems--"people almost always have connectivity" is some...like...zeroth world stuff.