Live data from Hacker News

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

dropboxforum.com

181–190 of 429 posts

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

#181
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…

NFS is probably the most unreliable network file system that is still in use.

Even SMB is better

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

#182
post #49
post #45

Earlier quoted context omitted.

It really sums up nerds' lack of comprehension of the importance of user experience. It's like the UX version of the apocryphal "640k is all anyone will ever need."

The other famous one of those is "No wireless. Less space than a nomad. Lame." https://slashdot.org/story/01/10/23/1816257/apple-releases-i...

I know it's usually taken as an example, but I disagree. CmdrTaco was giving his opinion, not saying it would fail in the market. To him, it was lame.

This idea that we're always making sale predictions is a vice of the startup culture.

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

#183
post #62
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…

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.

Those same Linux users know they can just download rclone which is the client that has support for backblaze ;)

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

#184
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

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

My top five in the 'Average Energy Impact' column of the Energy tab in Activity Monitor, as of this moment:

Docker (3.13) Dropbox (2.08) Outlook (2.03) Safari (2.02) Slack (1.57)

Total 131771 files currently on disk (I'm using Selective Sync, because SSD prices)

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

#185

Earlier quoted context omitted.

Similar to the Mac backup software Arq, just give me a list of object stores I can point to (Backblaze would be my first pick). Although, for my purposes, I think iCloud Files is going to turn into most of what I need from Dropbox fast enough that'll be where I move to.

For whatever reason, no other service does binary delta uploads like Dropbox, including Google drive. No other service takes advantage of the local network when syncing multiple PC's on the same LAN.

[deleted]

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

#186

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

Are you telling me that I could build a startup with 3 lines of bash? (EDIT: and a fancy easy windows version)

A great many successful tech companies can be described in terms of more consumer-friendly Unix tools.

Slack has the better part of a billion dollars in funding for what's essentially resource-hungry IRC with pictures. Dropbox does little you couldn't accomplish with a server and rsync.

What I'm really eager to see is git for everyone else.

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

#187
post #168

Earlier quoted context omitted.

I guess you could say it runs of everything unless you use one of the two most popular operating systems in the world: Android and iOS.

There's syncthing for Android: https://github.com/syncthing/syncthing-android

Whoops, the website could make that more clear. "Works on Mac OS X, Windows, Linux, FreeBSD, Solaris and OpenBSD."

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

#188

Earlier quoted context omitted.

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

Not if you consider speed and CPU consumption.

And it getting out of sync with reality. Metadata on the files seems much better.

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

#189
post #164

Earlier quoted context omitted.

> But where would you sync to? You sync across your devices (or anything where you can run a standalone binary). Phone, PC, server, whatever. It's pretty good and very stable when your packager doesn't fuck up the service file ( https://svnweb.freebsd.org/ports/head/net/syncthing/files/sy... ). > without the need to set up configure your home nas That's only needed if you need access to your files from the outside wo…

On my "ideal" requirements list is the ability to sync, encrypted, to a standard cloud backend as well. https://github.com/syncthing/syncthing/issues/2647

Then use git-annex, which has had that for years :)

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

#190

Earlier quoted context omitted.

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

Not if you consider speed and CPU consumption.

Yes, on file hashes for rename detection:

It prevents a whole lot of pipeline and concurrency optimizations since it forces you to rehash every file in the change set, before your rename detection algorithm can kick in.

For example, if a user renames a root folder with tens of thousands of descendants, then the hash approach would have poor time-to-first-change-synced latency.

Furthermore, relying on file hashes won't actually work.

A user could have done both a RENAME and UPDATE on the file, since the sync app last ran (you need scanning logic for this, and can't rely solely on inotify). To survive a RENAME and UPDATE, you would then need to compare partial file hashes. But again, it affects latency too much.

Post reply on HN