My one-liner Linux Dropbox client • Hacker News Board

Re: My one-liner Linux Dropbox client

#21

Post by zapzupnz » Tue, Dec 25, 2018, 12:27 PM UTC

dewey wrote: post #14

conanthe wrote: post #12

Dropbox is a no no for one simple reason - there is no end to end encryption. Unless I don't know something? I wouldn't want a disgruntled employee to fiddle with my files.

Just sync an encrypted image if your threat model includes disgruntled employees motivated enough to mess with your account.

Could be problematic if the image is huge.

Re: My one-liner Linux Dropbox client

#22

Post by mooreds » Tue, Dec 25, 2018, 12:28 PM UTC

Previous discussion of entr: https://news.ycombinator.com/item?id=13856623

Re: My one-liner Linux Dropbox client

#23

Post by ekianjo » Tue, Dec 25, 2018, 12:35 PM UTC

It's kind of funny to replace a proprietary client for a proprietary service with FOSS tools when you could completely replace Dropbox with FOSS alternatives instead and enjoy Freedom: Syncthing works very well, and while syncing is not its main feature you could also work with nextcloud.

Re: My one-liner Linux Dropbox client

#24

Post by tssva » Tue, Dec 25, 2018, 12:36 PM UTC

Since it is being used with systemd a systemd path unit could be used to monitor the file system removing the need to use entr.

Re: My one-liner Linux Dropbox client

#25

Post by panzerklein » Tue, Dec 25, 2018, 12:38 PM UTC

I setup Syncthing [1] to do the same for my vimwiki folder. It was surprisingly easy, and doesn't require any external storage services. And it can even automatically sync files without internet, over the local network.

[1] https://syncthing.net/

Re: My one-liner Linux Dropbox client

#26

Post by ubercow13 » Tue, Dec 25, 2018, 12:48 PM UTC

zapzupnz wrote: post #21

dewey wrote: post #14

Earlier quoted context omitted.

Just sync an encrypted image if your threat model includes disgruntled employees motivated enough to mess with your account.

Could be problematic if the image is huge.

You could use something like gocryptfs that encrypts at the file level

Re: My one-liner Linux Dropbox client

#27

Post by discordianfish » Tue, Dec 25, 2018, 1:10 PM UTC

lloeki wrote: post #13

> Recently, the proprietary Dropbox Linux client dropped support for all Linux file systems except unencrypted ext4. What the heck. Anyone has more information about that? Any announcement? And why would it fail to work on an encrypted (LUKS?) ext4 FS when encryption seemed to me to sit below the filesystem (since AFAIK ext4 doesn't support encryption itself)?

It's FUD. ext4 with LUKS, which is what pretty much everyone is using on a desktop, is still working and the client supported.

Re: My one-liner Linux Dropbox client

#28

Post by amenod » Tue, Dec 25, 2018, 1:18 PM UTC

tssva wrote: post #24

Since it is being used with systemd a systemd path unit could be used to monitor the file system removing the need to use entr.

Thanks, didn't know systemd can do that [0]! I must grudgingly admit that it seems to be quite useful, though I still don't like having a single app doing all that stuff. But that's off topic... :)

[0] https://blog.andrewkeech.com/posts/170809_path.html

Re: My one-liner Linux Dropbox client

#29

Post by viraptor » Tue, Dec 25, 2018, 1:19 PM UTC

jeremysmyth wrote: post #5

therealidiot wrote: post #4

Why does the client care which filesystem you use???

Different supported features make it easier to maintain such a client. Example: Some filesystems notify observers on file change, some don't.

This shouldn't affect other local filesystems though. Inotify won't work with NFS, but should be ok with fs owned by the local system.

Re: My one-liner Linux Dropbox client

#30

Post by hellcow » Tue, Dec 25, 2018, 1:23 PM UTC

panzerklein wrote: post #25

I setup Syncthing [1] to do the same for my vimwiki folder. It was surprisingly easy, and doesn't require any external storage services. And it can even automatically sync files without internet, over the local network. [1] https://syncthing.net/

I've been using Syncthing for more than a year across ~6 machines to keep them in sync. It works great for more complex setups than the article describes.