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

131–140 of 429 posts

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

#131

Post by laumars »

rayiner wrote: post #100
laumars wrote: post #65

Earlier quoted context omitted.

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…

In that case it might have been helpful if you stated that you were shifting the context away from FTP; as was the context in the GPs comment. ;)

NFS and AFS (from what limited I know of it) are more designed for local networks thus to leverage NFS over a WAN you'd then need to tunnel your connection (eg via SSH or VPN). So while there is obviously overlap between them and Dropbox I wouldn't really say the two are all that comparable.

However to answer your point, I don't think anyone would disagree with the specific part of your point regarding how simplicity is often better than something arguably more powerful. However just because something is simple it doesn't mean it isn't also good. "Good" is just a question of whether it meets requirements. If your requirement is that it can be installed and operated by layman then Dropbox is a far better solution than any other the other proposals you've mentioned.

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

#132

Post by raverbashing »

_urga wrote: post #95
gnufied wrote: post #35

Earlier quoted context omitted.

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

Or you keep a local db of synced files and compare hashes

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

#133

Post by anderspitman »

For 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 eventually, though. It's a fairly new feature if I'm not mistaken. For now, if I really just need to get a file from point A to point B right now, I used File Pizza.

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

#134

Post by mynegation »

As a developer I understand that each supported filesystem adds development workload and potential for bugs and at some point you need to weigh this cost against the benefit. The problem with this is that the people who use these filesystem are more likely to be opinion makers for other people in the choice of file syncing solution. Dropbox is big enough so they think they do not have to worry about it. But there is a real possibility that they will alienate just enough influential people, that this will erode their user base more than they realize.

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

#135

Post by pjc50 »

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

There has never been a network file system that really worked for this use case - detached operation by average users. The nearest we ever got was WebDAV.

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

#136

Post by dagw »

SEJeff wrote: post #117

That's cool dropbox, us Linux users prefer services like tarsnap anyways: http://www.tarsnap.com/ Colin is the founder, and also a HN celebrity because of this comment (which he regrets, but never gets old): https://news.ycombinator.com/item?id=35079

As much as I like tarsnap, comparing it Dropbox makes no sense at all. They do completely different things.

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

#137

Post by michaelcampbell »

rayiner wrote: post #87
michaelcampbell wrote: post #78

Earlier quoted context omitted.

Your situation is different than mine; this is the first I've heard of Dropbox even registering as a top use of battery. How many files do you have? I've got 26000 files in my Mac's dropbox folder. (Granted, very few of them change more than once or twice a day; maybe 20 or so of those do.)

I last used Dropbox in 2011 or so (I stopped using it because it killed my battery life). It may have gotten better since then. (But my point is addressed to what it takes to get popular, i.e. that its easier to make a “dumb” tool popular, and Dropbox was popular back then.) EDIT: Clearly not just me: https://news.ycombinator.com/item?id=12464901 (thread from 2016)

> i.e. that its easier to make a “dumb” tool popular,

If this was your intent, then using the tired "worse is better" trope and claiming an issue from 7 years ago, that no one else has claimed to have seen is seems a far cry from it.

Dropbox became popular because it was easy, it worked, and did exactly what it said it did. That might be "dumb" in that it's not feature packed, but you use a lot of negative connotations when none are required.

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

#138

Post by majewsky »

londons_explore wrote: post #5

Their reasoning of "you need a filesystem which supports extended attributes" sounds legit. Time for some of us to start work on adding extended attributes to more filesystems?

XFS is well-known for its extremely good xattrs support, so that does not add up.

Source: Using XFS at work for OpenStack Swift, which makes extensive use of xattrs and thus prefers to run on XFS.

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

#139

Post by Vash63 »

gnufied wrote: post #64
koolba wrote: post #59

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

My /home is XFS on my Arch system and I received the same popup from the Dropbox client. I can confirm that this does apply to XFS as well.

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

#140

Post by jorvi »

rcarmo wrote: post #39
shittyadmin wrote: post #8

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.

If you feel comfortable with Google, Gdrive has a great client in the form of OverGrive.
Post reply on HN