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

111–120 of 429 posts

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

#111

Post by krn »

pjc50 wrote: post #42
WorkLifeBalance wrote: post #9

No problem, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.

The modern alternative is probably Syncthing. I intermittently maintain a list of these things at https://github.com/pjc50/pjc50.github.io/blob/master/secure-... ; none of them have ever been precisely what I wanted. The cheap alternative to Dropbox with Linux support you want was "Hubic" from OVH (edit: now discontinued)

> The cheap alternative to Dropbox with Linux support you want is may be "Hubic" from OVH.

Hubic has been discontinued recently as a non-core business to OVH[1].

[1] https://www.ovh.co.uk/subscriptions-hubic-ended/

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

#112

Post by Spooky23 »

Alex3917 wrote: post #77
pjc50 wrote: post #49

Earlier quoted context omitted.

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

The first iPod was terrible though and sold poorly. The 3G was the first good model, and they didn’t start taking off until the 4G. History only proves that his analysis was completely correct.

It was firewire only for awhile too.

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

#113

Post by detaro »

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.

That certain subset seems to most likely to adapt their setups to just use ext4 if that's what's supported?

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

#115

Post by sp332 »

rcarmo wrote: post #48
nebulous1 wrote: post #30

Earlier quoted context omitted.

Not in the latest Ubuntu installs. They do FDE instead of home folder encryption.

The option to encrypt your home folder is still there in Ubuntu 18.04 (which I set up only yesterday), and appears after you set up volumes upon initial user creation. It is (funnily enough) even possible to enable _both_ kinds of encryption simultaneously. I'd say that they don't use full-disk encryption _instead_ of home folder. They just prompt for it sooner (and it is not the same thing if you have a modestly old…

I just spun up an 18.04.1 install in a VM to check, and I don't see an option to encrypt the user's homedir during installation.

Edit: It's listed under "Other base system changes since 16.04 LTS" https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes

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

#116

Post by Legogris »

mrd999 wrote: post #61
api wrote: 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."

It's not merely UX. At the heart of utility, you'll find simplicity and efficiency of use.

I'd argue that "simplicity and efficiency of use" clearly falls under User eXperience.

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

#117

Post by SEJeff »

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

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

#119

Post by jonknee »

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)

Going out on a limb here, but I think it's possible things have changed in 7 years (and that it was probably something specific to your setup, not something millions of Dropbox users with a Mac had to put up with).

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

#120

Post by blattimwind »

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…

extN xattrs are fairly limited, because iirc all xattrs of a given inode must be stored in the same block. I don't think XFS has any serious limitations (count/size) for them, but the Linux kernel itself limits the size to 64K.
Post reply on HN