Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dropboxforum.com

Post reply on HN
Print view View original

91–100 of 429 posts

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

#91

Post by OskarS »

vxNsr wrote: post #68
XorNot wrote: post #62

Earlier quoted context omitted.

It's because Linux users know what they're getting and store more data then "regular" users. It's the same reason "unlimited" storage plans from Backblaze don't have a Linux client.

Yeah, this is probably about cutting out the big data users. They don't even offer an unlimited plan, but they probably noticed that certain linux users were using most of their 2tb plans while everyone else wasn't. Lose the most active users, keep the ones paying for something they don't need.

Dropbox for Business is unlimited, isn't it?

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

#93

Post by bandrami »

jhasse wrote: post #71
sp332 wrote: post #58

Earlier quoted context omitted.

Ubuntu uses ext4 and the default is to ecryptfs the user's homedir. Edit: Actually I can't find that it was ever the default , but it was a pretty prominent option so I assume this decision is going to mess with a ton of customers.

Encryption is opt-in, not the default.

It's not even opt-in on Bionic anymore (at least, that checkbox is gone from the installer where you enter your user info)

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

#95

Post by _urga »

gnufied wrote: post #35
raverbashing wrote: post #4

> we’re ending support for Dropbox syncing to drives with certain uncommon file systems . The supported file systems... and Ext4 for Linux. Yeah this is not how it works. This is not how any of this works

That statement is bit dubious. The next line also says: > 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. Certainly XFS supports xattr and hence ideally should be supported. I don't…

I noticed Dropbox started setting their own xattrs on my files a year or two ago if I recall correctly.

My guess at the time was that they were using it for cheaper rename detection, using an xattr UUID, instead of using heuristics to compare {inode, btime, mtime, size, name, folder}.

In other words, they would match up the xattr UUID across CREATE and DELETE events to merge them into RENAME events.

Missing RENAME events is pretty bad for the user experience as it can lead to a loss of version history when the file ID changes through the DELETE, CREATE events.

Anyone have any other ideas as to why they would be reliant on xattrs?

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

#96

Post by scott_s »

vxNsr wrote: post #68
XorNot wrote: post #62

Earlier quoted context omitted.

It's because Linux users know what they're getting and store more data then "regular" users. It's the same reason "unlimited" storage plans from Backblaze don't have a Linux client.

Yeah, this is probably about cutting out the big data users. They don't even offer an unlimited plan, but they probably noticed that certain linux users were using most of their 2tb plans while everyone else wasn't. Lose the most active users, keep the ones paying for something they don't need.

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 multiplicative when a platform has multiple file systems).

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

#97

Post by [deleted] »

rayiner wrote: post #46
montecarl wrote: post #15

Earlier quoted context omitted.

Just in case anyone doesn't recognize this quote, it is from the 2007 hacker news post about Dropbox: https://news.ycombinator.com/item?id=8863

It’s a really great example of worse is better.[1] We went from sophisticated network file system to a daemon that destroys your battery life (at least on Mac) watching for file changes in a directory. [1] https://www.dreamsongs.com/RiseOfWorseIsBetter.html

[deleted]

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

#99

Post by dmoreno »

Another alternative is nextcloud... It also has a sync desktop client and works great in my company for sharing folders with colleagues or keep business documents in sync on desktop and laptop.

There are even third parties that install it and manage it for you.

[1] https://nextcloud.com/

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

#100

Post by rayiner »

laumars wrote: post #65
rayiner wrote: post #46

Earlier quoted context omitted.

It’s a really great example of worse is better.[1] We went from sophisticated network file system to a daemon that destroys your battery life (at least on Mac) watching for file changes in a directory. [1] https://www.dreamsongs.com/RiseOfWorseIsBetter.html

FTP is neither sophisticated nor a network file system. Frankly I'd take Dropbox over FTP any day of the week - FTP needs to die. Thankfully your options are not limited to either Dropbox or FTP. Thus people who want simplicity can have Dropbox (or similar) and people who want control can have sshfs or any number of other tools out there that require some assembly but also don't suffer from the numerous problems that…

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

If you were trying to make a “good” solution to the problem addressed by Drop Box, it probably would not look like Drop Box. For example, you’d do a real network file system that wouldn’t need to do a binary diff of the file each time to see what changed, because it would have access to the block level changes at the file system layer.[1] You'd have file locking in the protocol (like CFS), and could sync data from a locked file instead of waiting for the lock to be released.[1]

It also probably wouldn’t have made Houston a billionaire because who is going to install a kernel driver off the internet? But on the flip side, Dropbox almost certainly killed much of the interest in real network file systems, because it is good enough.

Which is why we’re all using an internet powered by Javascript, Electron apps on the desktop, etc. Worse is better.

[1] https://www.dropbox.com/help/syncing-uploads/upload-entire-f...

[2] https://www.dropbox.com/help/syncing-uploads/stuck-syncing

Post reply on HN