Live data from Hacker News

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

dropboxforum.com

331–340 of 429 posts

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

#332
Ugh, I use Dropbox on several platforms, some NTFS, some APFS, some HFS and exFAT. The majority of my files are synced to exFAT because it's the only bloody filesystem that's officially supported across all major OS. No it doesn't support extended attributes and I don't care, 95% of my files are photos!

If Dropbox go ahead with this I'm bailing. The only reason I use a managed service like this is so I don't have to care about the technical details (filesystems etc.)

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

#333

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”. :-)

This whole article read (to me!) as them wanting to reduce test load, and probably workarounds in their codebase.

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

#334

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?

Your two choices unnecessarily rule out a third: that Dropbox client phones home what filesystem is in use, and so they have concrete data backing their assertion.

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

#335
post #326

Earlier quoted context omitted.

> 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 som…

> with syncthing, you need to operate every piece of the system.

Again, this is false. The P2P relay/discovery nodes are operated by third parties donating server time and bandwidth. The user is not required to operate those parts of the network.

> That's an unrelated topic.

Definitely related to storage provisioning.

> This is about the total size of your data and whether it fits on multiple devices without inconvenience.

Convenience is entirely dependent upon the user's requirements. As I said, each node is not required to maintain full replication.

> you can save your data without needing to have enough space to have a full local copy

I'm not sure that putting a significant fraction of one's proverbial eggs in one basket is a selling point.

> If you're doing it yourself, you're taking on that responsibility entirely yourself.

I would add that you're always responsible for your data, third parties or not.

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

You and I could tell those people until we are both blue in the face, they are not going to learn until they have experienced it themselves.

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

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

Just put /home on a separate partition and please the BOFH gods.

I'm surprised to hear anyone is still mounting home and root on the same partition, frankly. It's made my life sooo much easier since I started doing it ages ago.

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

#337
post #293

Earlier quoted context omitted.

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…

> but there are tools to secure an outdated app in other ways either.

Not really.

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

#338
post #126
post #55

Earlier quoted context omitted.

Sorry, Google Drive doesn't support Linux.

No official support, but you can easily access the content read/write in multiple ways. I've used such a few years ago with a FUSE module, written in OCaml. The only complicated, annoying thing was getting authentication to work.

I've heard of it but is that reliable? I meant I'm a bit afraid of loosing data by using unofficial programs.

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

#339

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?

> the default filesystem used by the most popular distro.

Ubuntu doesn't use ecryptfs (or even support it afaik) by default.

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

#340

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.

Err... I can’t imagine a scenario where one would want to use OneDrive/Dropbox to sync git repositories. It’s like having your local Dropbox folder inside your local OneDrive folder — only a lot worse.
Post reply on HN