News for hackers. Stuff that matters.

A comment on My one-liner Linux Dropbox client. Parent comment

Re:My one-liner Linux Dropbox client by shocks on Tuesday December 25, 2018 @09:41AM (#18757578)
Doesn’t work on ZFS either. I dropped Dropbox because of this.
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by AntiqueFig on Tuesday December 25, 2018 @11:38AM (#18757962)
You can create a zvol for your dropbox folder and format it in ext4 and it'll work: https://pthree.org/2012/12/21/zfs-administration-part-xiv-zv...
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by sp332 on Tuesday December 25, 2018 @10:20AM (#18757703)
Or btrfs. Good thing I had a spare external hard drive I could dedicate to dropbox storage, because I'm sure not converting my drive array to a different FS just for that.
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by monochromatic on Tuesday December 25, 2018 @09:54AM (#18757616)
Why would an application like this care what file system it’s running on?
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by int0x80 on Tuesday December 25, 2018 @01:27PM (#18758558)
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:

https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/

[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by userbinator on Tuesday December 25, 2018 @01:40PM (#18758637)
Encryption is another problem.

I thought the whole point of an encrypting filesystem was that applications using it would not need to care about such things? Unless you're going below the FS abstraction and actually accessing blocks of the device directly, it shouldn't matter.

[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by geofft on Tuesday December 25, 2018 @02:45PM (#18758903)
One of the weird things about an encryption layer on top of a filesystem like eCryptFS (as opposed to encrypted block storage) is that it needs to encrypt and MAC the filenames somehow, but the underlying filesystem has maximum lengths on the filenames, so whatever space you're using for padding and authentication code needs to be squeezed in. And you also need to potentially find an encoding of the encrypted data in case the underlying filesystem doesn't treat filenames as bytes-except-for-ASCII-slash (e.g., common Mac and Windows filesystems treat filenames as Unicode of some form, and Mac ones even do canonicalization). So, your encrypted filenames end up being longer than your decrypted filenames, which means that your maximum filename length is shorter than the underlying filesystem's maximum length.

For a system like Dropbox, which automatically renames files to things like "file.txt (userbinator's conflicted copy 2018-12-25)", this is a problem. For eCryptFS, whose limit is "we typically recommend you limit your filenames to ~140 characters", (https://unix.stackexchange.com/a/32834), the uncertainty is a problem too.

Dropbox could make this work (and did in the past), but they decided it would be more reliable to say they won't try and won't make promises about their client working 100% of the time on these filesystems. (And I guess their support or business department was not thrilled with the option of "we'll let you try but we won't support you even though you're paying".)

[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by int0x80 on Tuesday December 25, 2018 @01:59PM (#18758718)
With LUKS it doesn't matter. But not all encryption methods are like that. That was just really an example of potential differences. In fact, when this (Dropbox dropping non ext4 support) happened the problem that triggered this was encryption related IIRC.
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by ric2b on Wednesday December 26, 2018 @01:52PM (#18763871)
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.
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by int0x80 on Wednesday December 26, 2018 @07:57PM (#18766298)
I agree here. But they just want to cover their asses I guess.
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by hannasanarion on Tuesday December 25, 2018 @10:26AM (#18757720)
It shouldn't have to. Dropbox ran fine on all filesystems for years. In September they sent everybody an email basically saying "you can't use Dropbox anymore, bye bye"
[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by sly010 on Tuesday December 25, 2018 @10:30AM (#18757737)
If I care to guess, because if you go an abstraction lower you can do your job better. Dropbox actually uses kernel drivers on some platforms (not sure on Linux).

I guess power users are not the target market.

[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by Spivak on Wednesday December 26, 2018 @05:13PM (#18765375)
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.

[ Parent | on HN ]
Re:My one-liner Linux Dropbox client by toomuchtodo on Tuesday December 25, 2018 @10:25AM (#18757715)
Filesystem primitives the application requires to deliver the desired functionality.
[ Parent | on HN ]