Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My one-liner Linux Dropbox client

lpan.io

Post reply on HN
Print view View original

151–160 of 165 posts

Re: My one-liner Linux Dropbox client

#151

Post by ric2b »

int0x80 wrote: post #87
monochromatic wrote: post #49

Earlier quoted context omitted.

Why would an application like this care what file system it’s running on?

In principle I agree with you, and many could argue the the app is broken. But in all fairness it is not so easy. Then there are lots of little details and corner cases where filesystems that implement a POSIX fs have slightly different semantics. This is important for example when dealing with sync'ing files to disk/backend. Encryption is another problem. Error handling. See for an example the annoying details here:…

They could just give you warnings that the FS isn't supported. Instead the client refuses to run if it's not on a supported FS, even though it would very likely work fine.

Re: My one-liner Linux Dropbox client

#152

Post by jogundas »

yjftsjthsd-h wrote: post #35
jogundas wrote: post #34

Earlier quoted context omitted.

Though very useful, syncthing unfortunately uses direct communication which leads to problems with port forwarding.

They have relay servers.

Thanks, did know about that! https://relays.syncthing.net and https://docs.syncthing.net/users/relaying.html .

Re: My one-liner Linux Dropbox client

#153

Post by Spivak »

FullyFunctional wrote: post #137
discordianfish wrote: post #27

Earlier quoted context omitted.

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

Be more respectful. It broke my workflow which is having my $HOME on NFS which is also nuked with the stupid Dropbox change.

Add it to the already long list of software that misbehaves over NFS.

Ceph/RBD with the filesystem of your choice that supports xattrs is pretty much the only way to get full application compatibility.

Re: My one-liner Linux Dropbox client

#154

Post by Spivak »

monochromatic wrote: post #49
shocks wrote: post #47

Earlier quoted context omitted.

Doesn’t work on ZFS either. I dropped Dropbox because of this.

Why would an application like this care what file system it’s running on?

Because different filesystems have different features and xattrs is one which isn't implemented everywhere.

Another example of features not implemented everywhere is the cornucopia of file locking APIs which is why SQLite doesn't officially support being run on NFS.

Re: My one-liner Linux Dropbox client

#155

Post by Spivak »

GordonS wrote: post #114
algo646464 wrote: post #73

Earlier quoted context omitted.

The above is a great answer. To expand on this (from some googling). All of this requires root. 1) Create a sparse file (actual size depends on usage) truncate -s 100G /home/zzz/Dropbox.image 2) Create a ext4 filesystem on it mkfs.ext4 -m0 /home/zzz/Dropbox.image 3) Mount it as a loopback file system sudo mount /home/zzz/Dropbox.image /home/zzz/Dropbox-fs 4) Create / Copy your dropbox folder to Dropbox-fs sudo mkdir…

I've never heard of a 'loopback filesystem' before. Can you expand a little on what this is?

The right term is a 'loopback device' which allows you to use a file on an existing filesystem as a block device.

Here's what the flow looks like:

open(/path/to/myfile) ->

ext4 driver ->

block operations on /dev/loop0 ->

open(/path/to/loop-file) ->

block operations on the data region of the file ->

btrfs driver ->

block operations on /dev/sda

Re: My one-liner Linux Dropbox client

#156

Post by Spivak »

viraptor wrote: post #29
jeremysmyth wrote: post #5

Earlier quoted context omitted.

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.

The mistake is assuming that there's something special about 'local' filesystems. They have as much feature disparity as networked ones.

Re: My one-liner Linux Dropbox client

#157

Post by int0x80 »

ric2b wrote: post #151
int0x80 wrote: post #87

Earlier quoted context omitted.

In principle I agree with you, and many could argue the the app is broken. But in all fairness it is not so easy. Then there are lots of little details and corner cases where filesystems that implement a POSIX fs have slightly different semantics. This is important for example when dealing with sync'ing files to disk/backend. Encryption is another problem. Error handling. See for an example the annoying details here:…

They could just give you warnings that the FS isn't supported. Instead the client refuses to run if it's not on a supported FS, even though it would very likely work fine.

I agree here. But they just want to cover their asses I guess.

Re: My one-liner Linux Dropbox client

#159

Post by luckman212 »

ApolloRising wrote: post #136
luckman212 wrote: post #77

Earlier quoted context omitted.

I've used Syncthing and it's excellent. But for me, the lack of a mobile app was a dealbreaker. Even though it's not open source, I switched to Resilio Sync[1] (formerly known as btsync). It ticks all the other boxes, and just works amazingly well. I want to support them so I sprang for the $20 one time Pro license which adds selective sync and a few other nice features. [1] https://www.resilio.com/individuals/

Does Resilio sync encrypt the file names and folders during sync or just the data?

All traffic between peers is encrypted. You can read more about the encryption below[1]. You can also create encrypted (at rest) folders[2] for replicating via public clouds while still maintaining 100% privacy.

[1] https://help.resilio.com/hc/en-us/articles/205451025-Can-oth...

[2] https://help.resilio.com/hc/en-us/articles/207370466-Encrypt...

Re: My one-liner Linux Dropbox client

#160

Post by pmlnr »

pritambaral wrote: post #63
pmlnr wrote: post #50

Earlier quoted context omitted.

No, it's not FUD. encrypted ext4 is encfs and ecryptfs, not xy on LUKs, and yes, they did drop support.

Just FYI: Ext4 has file-level encryption built-in now [1, 2], so 'encrypted ext4' is actually different from encfs and ecryptfs. [1]: https://www.kernel.org/doc/html/v4.19/filesystems/fscrypt.ht... [2]: https://wiki.archlinux.org/index.php/ext4#Using_file-based_e...

I didn't know this, that's new for me.
Post reply on HN