Live data from Hacker News

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

dropboxforum.com

321–330 of 429 posts

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

#321

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…

An easier option at the moment is probably SyncThing which just syncs directly between your devices. I use it for sending my KeePass DB and photos from my phone to my NAS.

If you're willing to invest setup effort it might also be worth considering Tahoe-LAFS's "GridSync" which seems to be making some progress as of late.

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

#322
post #96

Earlier quoted context omitted.

Are you and XorNot guessing, or are you basing this off a statement they made? Because the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems. That complicates development quite a bit (because you need to have developers who know the quirks of the file systems) and testing a lot (because all changes have to be tested on all variants, and it becomes multip…

> the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems. But they don't have to maintain a bunch of different filesystems. That's the OS's job. From the application's PoV there shouldn't be any difference between these filesystems, all they need to do is check if the required feature (xattrs) is enabled for a certain FS and that's all.

You still need to test. And I'm skeptical that there is no observable difference from the application level.

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

#323

Earlier quoted context omitted.

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…

I'm going to make the argument that Dropbox doesn't support Windows, because they don't support FAT32. That's just as true as your argument that they don't support Linux, because they very much do still support Linux.

You can't install Windows on FAT32. I'm pretty sure your home directory (where the Dropbox folder is) can't be on FAT32 either. About the only thing that uses FAT32 are USB sticks smaller than 32GB. It is extremely unlikely anyone would want to run Dropbox on a FAT32 volume, and I suspect it has never worked due to the filesystem limitations. ie you would have to struggle to end up in this situation as a Windows user. And even if you did, I doubt any of their competition supports FAT32 either.

They are only partially supporting Linux already (eg no SmartSync). They are now removing support for the default configuration on many existing distros. They are removing support for setups that have worked for years, and earned them much revenue. It is their business and they can do what they want. Linux support is what distinguishes them from their competitors. And now they will lose future revenue from me and others who have posted here about it. Also note that their technical explanation is complete nonsense which is exacerbating the problem. Hopefully they will revisit the decision, or communicate in more detail what the problem actually is. I have no doubt that Linux will fix whatever it is.

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

#325

Earlier quoted context omitted.

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."

There was also a series of issues found by with the encryption used by ecryptfs: 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.

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

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

#326
post #263

Earlier 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 That's a vague assertion that can apply to anything. > provision enough storage to hold everything Syncthing can ignore directories/patterns at the local level. > secure them And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices. > have a backup plan…

> > run the various computers > > That's a vague assertion that can apply to anything.

It's a very specific assertion which does not apply to every thing: with syncthing, you need to operate every piece of the system. With a cloud service, you are delegating that to other people, presumably professionals. That's a big difference for most people and it has significant implications for things like backups — e.g. if someone breaks into your house and steals two computers, did you just lose every copy of your data?

> > provision enough storage to hold everything > > Syncthing can ignore directories/patterns at the local level.

That's an unrelated topic. This is about the total size of your data and whether it fits on multiple devices without inconvenience. If you have a phone and a laptop, do you have enough storage for a full copy of everything? If not, you need to add a third computer, deal with external drives, etc. One appeal of cloud services for many people is that you can save your data without needing to have enough space to have a full local copy and still be able to access it.

> > secure them > > And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices.

Again, this is a comparison question. A service has a separate security trust boundary so someone who compromises your account doesn't get infrastructure-level access and cannot permanently delete things without you having a chance to recover. If you're doing it yourself, you're taking on that responsibility entirely yourself. Maybe you're confident with that, maybe you're not but it's something that you absolutely have to think about for a data storage system.

> > have a backup plan > > Another non-sequitur. Either tool can be part of a backup solution.

You might want to check the definition of non-sequitur – it's not a get-out-of-jail-free card for avoiding an answer. Just to reiterate, ask what happens if your hard drive starts corrupting blocks, someone steals your computer, your house burns down, you get malware which encrypts every file on your computer, etc. With Dropbox the answer is “I buy a new computer and restore my data. Since the malware couldn't overwrite the older copies, I lost nothing”. If you're self-hosting, that could have the same answer but it requires more skills and ongoing commitment to do things like off-site backups.

What I've found to be sadly common is that people do these comparisons without actually matching equivalent levels of service and then get a painful educational lesson when something goes wrong and they lose something they cared about.

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

#327

The kicker is in the couching - dropping support for "uncommon filesystems" - of which their definition includes the default filesystem used by the most popular distro. Just dumb or wilfully ignorant?

compare that with all their Windows and OSX user base, I guess it is less common filesystems.

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

#328
post #228

I have been using Resilio Sync on Linux, Mac, Windows, iOS, and Android, and it works a charm for me. In case this turns out to be a problem for you, maybe give them a try. Never an issue on Linux with Resilio Sync. I run a copy on my VPS in the cloud for remote storage.

I'm about to cancel my Dropbox subscription and move to Resilio, so I wanted to chime in and say I've had a great experience with Resilio in the past and my friends are also using it with great results.

Btw: Resilio Sync used to be known as BitTorrent Sync.

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

#329

Earlier quoted context omitted.

There was also a series of issues found by with the encryption used by ecryptfs: 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.

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes.

Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway.

Remote interaction is then required to bring the VMs on that system up.

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

#330

Earlier quoted context omitted.

There was also a series of issues found by with the encryption used by ecryptfs: 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.

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

On Debian-based systems including Ubuntu, they offer an initrd based Dropbear (lightweight SSH server) which can be used to connect and authenticate. Involved a bit of custom scripting last I checked though, but a possible solution if that's a requirement for you.
Post reply on HN