4 ms·

It appears this might be related to dropbox (mis)using statfs's f_fsid field as part of its authentication system. The dropbox devs apparently assumed that thi

• cbhl 8y ago
  Oof, although not surprising. Once saw a system that used inode numbers as "unique identifiers for files on local disk" and it turns out that on Linux / ext filesystems, they're not unique (they get reused if you delete a file and then create a new one). That team just decided to not support Linux at all.
• gkoberger 8y ago
  Sometimes it's not about assuming something is stable, but rather finding a workaround you need and hoping it lasts.
• chadaustin 8y ago
  That sounds to me like the most likely hypothesis in this thread. I mean, the Linux manpage itself says it's stable and can be used, with the inode number, to uniquely identify a file. http://man7.org/linux/man-pages/man2/statfs.2.html http://man7.org/linux/man-pages/man2/statfs.2.html I'm not surprised, though. Fancy copy-on-write filesystems like btrfs have some other subtle gotchas. If you allocate (like, really, not as a hole) a big file on btrfs and mmap it for write, you might see a SIGBUS upon writing because btrfs needed to recompress a block and the new compressed block didn't fit where the old one did. I've gained a new appreciation for the predictability and simplicity of ext4.