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

371–380 of 429 posts

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

#371

Post by StavrosK »

dylan-m wrote: post #306
Walkman wrote: post #267

This is exactly why I stopped using Dropbox and moved everything I have to my own https://nextcloud.com instance. It's very easy to install and upgrade, it is stable, have way more features than Dropbox and you have total control over your own data. Overall a superior experience. If they would do something I don't like, I would just never upgrade anymore and be done with it or just copy the files out of the /data/Nex…

I set up a little Ubuntu Core server with Nextcloud for archives and sharing, and Syncthing for slightly cleverer sync of files I'm actively working with. Syncthing is decentralized, and it's designed so you can just pick any folder and sync it between your devices, which makes for a really handy workflow. But I like good having a long-running server in the middle that I can treat as canonical. That way I have one pl…

This echoes my experience exactly. I use Syncthing for all the documents I don't need a web UI for or that I don't need accessible on mobile (only between computers), such as my ebooks, PDFs, things like that, and Nextcloud for everything else.

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

#372

Post by gkoberger »

nebulous1 wrote: post #361

It appears this might be related to dropbox (mis)using statfs's f_fsid field as part of its authentication system. The dropbox devs apparently assumed that this field was stable, but on XFS (for instance) it can change. dropboxforum thread here: https://www.dropboxforum.com/t5/Installation-and-desktop-app...

Sometimes it's not about assuming something is stable, but rather finding a workaround you need and hoping it lasts.

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

#373

Post by chadaustin »

nebulous1 wrote: post #361

It appears this might be related to dropbox (mis)using statfs's f_fsid field as part of its authentication system. The dropbox devs apparently assumed that this field was stable, but on XFS (for instance) it can change. dropboxforum thread here: https://www.dropboxforum.com/t5/Installation-and-desktop-app...

That sounds to me like the most likely hypothesis in this thread.

I mean, the Linux manpage itself says it's stable and can be used, with the inode number, to uniquely identify a file. http://man7.org/linux/man-pages/man2/statfs.2.html

I'm not surprised, though. Fancy copy-on-write filesystems like btrfs have some other subtle gotchas. If you allocate (like, really, not as a hole) a big file on btrfs and mmap it for write, you might see a SIGBUS upon writing because btrfs needed to recompress a block and the new compressed block didn't fit where the old one did.

I've gained a new appreciation for the predictability and simplicity of ext4.

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

#374

Post by JoshMnem »

wlesieutre wrote: post #24
thomasfedb wrote: post #10

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?

I'd bet that by Dropbox's user metrics "the most popular distro" still qualifies as "uncommon" for a Dropbox client. Despite being the year of desktop Linux, non-server Linux boxes are comparatively rare. That said, Ext4 is still supported, just not with encryption.

> Ext4 is still supported, just not with encryption.

It's a terrible idea to not turn on hard drive encryption. Anyone who gets their hands on the machine can read and write to the drive by booting it with a thumb drive.

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

#375

Post by JoshMnem »

freehunter wrote: post #311
rogerbinns wrote: post #309

Earlier quoted context omitted.

Of course my example is essentially irrelevant in isolation. But you do should understand that Dropbox is different than their competitors. Dropbox are the only ones who support Linux. Google Drive, Box, OneDrive etc do not support Linux (random partial featured third party clients do not count.) In places (eg tech) where there is a Linux user base (eg the developers, devops etc) then Dropbox was the main realistic s…

I'm going to make the argument that Dropbox doesn't support Windows, because they don't support FAT32. That's just as true as your argument that they don't support Linux, because they very much do still support Linux.

Running Linux without encrypting the drive is a big security risk. Anyone who can get their hands on the machine has full read and write access to the hard drive by booting with a thumb drive. Any company that uses Dropbox for Business and has employees who use Linux will be putting a security hole in their business if they decrypt their hard drives in order to use Dropbox. (Possibly including Dropbox, if any of their employees use Linux.)

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

#376

Post by Jedd »

StavrosK wrote: post #368
ronjouch wrote: post #245

Earlier quoted context omitted.

Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base... > "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."

Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

> Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

a) This hasn't ceased to work for your desktop - you can continue to do this through the upgrade cycle, as it would only affect new installs (safely converting native fs to dmcrypt isn't possible, AFAIK)

b) during an installation you could eschew FDE and opt for a PV, as I do, that you put your selected, secure LV's onto. I use Debian in preference to Ubuntu, but I'm sure they're materially identical in this case -- two physical partitions -- /boot and not-boot. /boot isn't encrypted in my case, but /, and /home (and a couple of others, though not swap of course) are LVM2 volumes sitting on top of the encrypted 'rest of the disk' partition. If you have /home only with noauto option in fstab , pointing to a an LV on the crypted partition, you could continue to do what you're doing, with the same reduced security confidence.

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

#377

Post by user5994461 »

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?

It's the default filesystem on RedHat, CentOS and Fedora. Looks like they will be dropping that.

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

#378

Post by Jedd »

ahnick wrote: post #359
eropple wrote: post #352

Earlier quoted context omitted.

When OneNote freaks out because it can't access its drive during an auto-save and hard-locks? When zsh can't start because it can't find files sourced in .zshrc? Yeah, that's kind of important and that should nev-er happen. "I copy files out of it to get around that it's not good at what I'm trying to use it for" is not a super winning argument, either. KBFS is fine. I use it for stuff like SSH keys. It's fine. It's…

You use the tool as it is intended. With Keybase if you are opening and working directly from the Keybase folder that is mounted then you are using it wrong, so your scenario wouldn't happen if you are using Keybase correctly. The point I was trying to make is that for many people being able to copy back and forth between a local folder and a mounted directory is no different than what they do everyday at work with n…

> You use the tool as it is intended. With Keybase if you are opening and working directly from the Keybase folder that is mounted then you are using it wrong, so your scenario wouldn't happen if you are using Keybase correctly.

You may be misunderstanding intent.

Consider https://keybase.io/blog/encrypted-git-for-everyone

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

#379

Post by user5994461 »

Spivak wrote: post #345
awill wrote: post #301

Earlier quoted context omitted.

Yep. Dropbox is going to lose some customers. Maybe it won't be too many (compared to Windows/Mac), but the customers they will lose will be their most technical.

How many customers do you think are running RHEL as a desktop workstation and allowed to use Dropbox?

If any, I bet they can be counted on one hand.

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

#380

Post by user5994461 »

enzolovesbacon wrote: post #205
WallWextra wrote: post #12

It's a shame that btrfs seems to be dead in the water. I guess nobody with the resources to build such a filesystem actually needs its snapshotting and integrity features at the filesystem level?

"dead in the water" is incorrect. SUSE's SLES (I believe OpenSUSE as well) uses btrfs on root and XFS on home for default install. And SUSE systems are very far from "dead in the water" as it's employed in lots of big servers around the globe. Just because Red Hat marked btrfs deprecated on their systems, doesn't mean the technology itself is deprecated. Also, from what I've read, they deprecated it because of resour…

The story goes that most of the btrfs developers were hired by Facebook.

SUSE is pretty much dead. Anything still running on that should be planning budget and resources for a migration.

Post reply on HN