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

351–360 of 429 posts

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

#351

Post by acdha »

snerbles wrote: post #335
acdha wrote: post #326

Earlier quoted context omitted.

> > run the various computers > > That's a vague assertion that can apply to anything. It's a very specific assertion which does not apply to every thing: with syncthing, you need to operate every piece of the system. With a cloud service, you are delegating that to other people, presumably professionals. That's a big difference for most people and it has significant implications for things like backups — e.g. if som…

> with syncthing, you need to operate every piece of the system. Again, this is false. The P2P relay/discovery nodes are operated by third parties donating server time and bandwidth. The user is not required to operate those parts of the network. > That's an unrelated topic. Definitely related to storage provisioning. > This is about the total size of your data and whether it fits on multiple devices without inconven…

> > with syncthing, you need to operate every piece of the system. > > Again, this is false. The P2P relay/discovery nodes are operated by third parties donating server time and bandwidth. The user is not required to operate those parts of the network.

Okay, let's think about this a bit more in depth: who's operating the computer which stores the data? If I have a laptop and a desktop, can my laptop backup its data if my desktop is powered off or my cable modem is down? If those third-parties decide to stop donating their time or something breaks and they don't have time to fix it, does my data still sync?

I don't see how the answers to any of those questions are compatible with “this is false” being a correct statement.

> You and I could tell those people until we are both blue in the face, they are not going to learn until they have experienced it themselves.

… and that's why for most people it makes sense to outsource these tasks to professionals who specialize in that work, just as most people pay mechanics to work on cars and contractors to fix their houses.

Again, my point was not that syncthing is bad but that an open-source project is not the same thing as a supported service. I get that you like this and want to evangelize it but misrepresenting what it does is just asking for someone to be disappointed.

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

#352

Post by eropple »

ahnick wrote: post #343
eropple wrote: post #320

Earlier quoted context omitted.

> I take your point that they use different mechanisms to provide access to files which are not fully interchangeable. With that said, I think many people probably don't really care or have a need for offline access, since nowadays people almost always have connectivity. Given this I would say in many (maybe most?) instances Keybase could replace Dropbox in practice. Yeah, no, I don't think so. If my bus or train goe…

Really? If you lose access to your dotfiles and OneNote notebooks for 5 or 10 minutes (that would be one long tunnel) that's completely unacceptable? This also sounds like a daily commute that could have easily been planned around if that time is really that important. Besides, when I work with Keybase I copy the files to my machine ahead of time to a local directory, so I likely would never notice such a drop in con…

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 not Dropbox and it isn't substitutable and it doesn't need capes.

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

#353

Post by cbhl »

h4b4n3r0 wrote: post #325
shittyadmin wrote: post #318

Earlier quoted context omitted.

There was also a series of issues found by with the encryption used by ecryptfs: https://defuse.ca/audits/ecryptfs.htm The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.

There is (or at least _was_ when I last tried FDE) one major fly in this ointment: you lose the ability to reboot your machine remotely. Upon restarting it required that you enter the password, which you can only do from a local keyboard.

You could put a daemon on the initramfs (say, ssh) that allows you to remotely provide a key/password for decrypting the disk.

This would certainly be more work to set up than vanilla full-disk encryption, though.

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

#354

Post by austurist »

mxuribe wrote: post #60
vxNsr wrote: post #51

Dropbox isn't even the cheapest or best file syncing service, they're basically all a commodity at this point and if they don't want you as customers... just go elsewhere.

Would you kindly provide recommendations? I'm looking for a sync service which can run on windows AND linux (which is why onedrive and google drive are out)...and i'm willing to pay a fair monthly fee.

What about Adrive? They don't have Linux client, but they support WebDAV, rsync, (S)FTP(S). I guess, getting some pretty stable client for these protocols won't be a challange.

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

#355

Post by bayindirh »

Why not run a small set of tests after installing and see whether the required set of FS features available?

Experienced users run plethora of filesystems which support the needs of dropbox.

IMHO, this is a lazy solution to a relatively simple problem.

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

#356

Post by MikeHalcrow »

shittyadmin wrote: post #318
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."

There was also a series of issues found by with the encryption used by ecryptfs: https://defuse.ca/audits/ecryptfs.htm The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.

Author of eCryptfs and EXT4 encryption chiming in.

"Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact.

That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast.

Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.

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

#357

Post by carini »

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…

nextcloud is fine, but I have a multi-function printer with scan-to-cloud support (very insecure, but VERY useful and super easy) that support only dropbox, box, microsoft amd google. I'll try rclone :-)

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

#358

Post by Zak »

exikyut wrote: post #243
Zak wrote: post #186

Earlier quoted context omitted.

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.

What would "everyone else" do with Git? It's a Rube Goldberg solution implementing a highly specific set of ways to do file versioning. Most cloud storage providers offer rudimentary versioning; are you referring to the idea of promoting commits to being first-class? It would need to be baked into Word, Excel and similar, and those tools already have builtin version tracking, as horrible(?) as it is, so... :/

People I know who definitely have this problem tend to work in creative fields - especially musicians and (digital) visual artists. They almost universally have a bunch of files with names like project_final2_revised_reallyfinal3_with_edits_from_sally.psd.

Of course, a solution that works well with all the different binary file formats people in those fields use wouldn't be easy.

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

#359

Post by ahnick »

eropple wrote: post #352
ahnick wrote: post #343

Earlier quoted context omitted.

Really? If you lose access to your dotfiles and OneNote notebooks for 5 or 10 minutes (that would be one long tunnel) that's completely unacceptable? This also sounds like a daily commute that could have easily been planned around if that time is really that important. Besides, when I work with Keybase I copy the files to my machine ahead of time to a local directory, so I likely would never notice such a drop in con…

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 networked folders. Many people are just moving the occasional document, picture, or folder. For those people Keybase could definitely work as a Dropbox replacement. I don't think the typical Dropbox user is expecting their ZSH profile to be omnipresent on their multiple computers/laptops/tablets.

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

#360

Post by azinman2 »

vxNsr wrote: post #350
azinman2 wrote: post #94

Earlier quoted context omitted.

Why do you say it isn’t the best?

I was gonna suggest onedrive but realized they don't have a linux client. Honestly for linux, dropbox might be your best bet...

What makes you say onedrive is better than Dropbox?
Post reply on HN