4 ms·

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

by shocks 8y ago

monochromatic 8y ago
Why would an application like this care what file system it’s running on?
- toomuchtodo 8y ago
  Filesystem primitives the application requires to deliver the desired functionality.
- hannasanarion 8y ago
  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"
- sly010 8y ago
  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.
- int0x80 8y ago
  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/ https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/ http://danluu.com/filesystem-errors/
  - userbinator 8y ago
    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.
    - int0x80 8y ago
      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.
    - geofft 8y ago
      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 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".)
  - ric2b 8y ago
    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.
    - int0x80 8y ago
      I agree here. But they just want to cover their asses I guess.
- Spivak 8y ago
  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.
sp332 8y ago
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.
AntiqueFig 8y ago
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-zvols/ https://pthree.org/2012/12/21/zfs-administration-part-xiv-zv...

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

by shocks 8y ago

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

monochromatic 8y ago

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

toomuchtodo 8y ago
Filesystem primitives the application requires to deliver the desired functionality.
hannasanarion 8y ago
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"
sly010 8y ago
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.
int0x80 8y ago
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/ https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/ http://danluu.com/filesystem-errors/
- userbinator 8y ago
  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.
  - int0x80 8y ago
    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.
  - geofft 8y ago
    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 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".)
- ric2b 8y ago
  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.
  - int0x80 8y ago
    I agree here. But they just want to cover their asses I guess.
Spivak 8y ago
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.

sp332 8y ago

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.

AntiqueFig 8y ago

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-zvols/ https://pthree.org/2012/12/21/zfs-administration-part-xiv-zv...