4 ms·

What are the benefits to doing this? From the article I got two, "wine can get the kernel to do case insensitive path stuff instead of emulating it itself", and

What are the benefits to doing this? From the article I got two, "wine can get the kernel to do case insensitive path stuff instead of emulating it itself", and "users don't need special userspace magic to treat their filenames as strings, not bytes". I have never seen anyone at all mope over lack of the latter, and the former seems quite specific to get such a big feature landed over. What other use-cases are there that benefit from this being in the FS?

MayeulC 6y ago
I think it might somewhat be required for interoperability with some other filesystems (exfat under some conditions, hpfs likewise). Moreover, as complex as the problem can be, it might come in handy to have a unicode normalization subsystem in the kernel for other modules to use. I don't think it's in the FS, but it's now a feature of the kernel that various FS can choose to wire up with, and expose knobs to the user to leverage it. Besides that, whether they do or not is their choice. But I believe this subsystem is going to get used a lot more than some other, obscure kernel areas ;)
- MayeulC 6y ago
  "edit": s/hpfs/apfs/
Sesse__ 6y ago
Samba is another case, and a very important one at that for a lot of users.
myself248 6y ago
I mope at the lack of the latter, and it kept me off linux for twentysome years. Only now that I do most of my work in a GUI and I just click on filenames rather than typing them, does a case-sensitive filesystem not grind my gears. Every time I have to cd Downloads instead of cd downloads, I wonder who thought that was a good idea. Case-sensitivity is a classic case of users being forced to comply with the computer's needs, rather than the other way around. I contend that that is Wrong, period. To put it another way: Unicode is the opposite. It is computers adopting complexity to serve the needs of humans. If we can do unicode, we can do case-insensitive filename matching. If we're going to insist on case-sensitivity and ignore the needs of human language, we should just go back to plain old ASCII and force the humans to comply with that too.
- mixmastamyk 6y ago
  Try setting the insensitive option in your shell. With hidden filenames on mobile, desktop GUIs, terminal CLI completion, and shells with insensitive matching like fish (bash via option), the benefits of insensitive fs are not as high as they used to be. Meanwhile, the complexity of matching modern Unicode causes performance degradation and exposes many edge cases. In short, the window of time where insensitive made sense has largely closed.
  - lmm 6y ago
    > With hidden filenames on mobile, desktop GUIs, terminal CLI completion, and shells with insensitive matching like fish (bash via option), the benefits of insensitive fs are not as high as they used to be. We've got better at working around case sensitivity, sure. I don't see that as a good reason not to fix the problem properly.
    - mixmastamyk 6y ago
      > Meanwhile, the complexity of matching modern Unicode causes performance degradation and exposes many edge cases. As mentioned, there is no way to "fix the problem properly" and a close-enough solution, rarely needed these days, slows performance.
jmgao 6y ago
> More recently, f2fs has started to support this feature as well, following the Ext4 implementation and framework, thanks to an effort led by Google. Most, if not all, of the information described here also applies to f2fs, with small changes on the commands used to configure the superblock. I'd guess that the f2fs changes at least are motivated by sdcard emulation on Android: sdcards were FAT32 in the beginning, so once they started being emulated with a backing store on the regular (ext4, then f2fs on pixels) data partition, case-insensitivity had to be emulated (first via a FUSE daemon in userspace, then via sdcardfs, a stackable FS in the kernel written by Samsung). (I work at Google on Android, but I don't have any first-hand knowledge about this.)

MayeulC 6y ago

I think it might somewhat be required for interoperability with some other filesystems (exfat under some conditions, hpfs likewise). Moreover, as complex as the problem can be, it might come in handy to have a unicode normalization subsystem in the kernel for other modules to use. I don't think it's in the FS, but it's now a feature of the kernel that various FS can choose to wire up with, and expose knobs to the user to leverage it. Besides that, whether they do or not is their choice. But I believe this subsystem is going to get used a lot more than some other, obscure kernel areas ;)

MayeulC 6y ago
"edit": s/hpfs/apfs/

Sesse__ 6y ago

Samba is another case, and a very important one at that for a lot of users.

myself248 6y ago

I mope at the lack of the latter, and it kept me off linux for twentysome years. Only now that I do most of my work in a GUI and I just click on filenames rather than typing them, does a case-sensitive filesystem not grind my gears. Every time I have to cd Downloads instead of cd downloads, I wonder who thought that was a good idea. Case-sensitivity is a classic case of users being forced to comply with the computer's needs, rather than the other way around. I contend that that is Wrong, period. To put it another way: Unicode is the opposite. It is computers adopting complexity to serve the needs of humans. If we can do unicode, we can do case-insensitive filename matching. If we're going to insist on case-sensitivity and ignore the needs of human language, we should just go back to plain old ASCII and force the humans to comply with that too.

mixmastamyk 6y ago
Try setting the insensitive option in your shell. With hidden filenames on mobile, desktop GUIs, terminal CLI completion, and shells with insensitive matching like fish (bash via option), the benefits of insensitive fs are not as high as they used to be. Meanwhile, the complexity of matching modern Unicode causes performance degradation and exposes many edge cases. In short, the window of time where insensitive made sense has largely closed.
- lmm 6y ago
  > With hidden filenames on mobile, desktop GUIs, terminal CLI completion, and shells with insensitive matching like fish (bash via option), the benefits of insensitive fs are not as high as they used to be. We've got better at working around case sensitivity, sure. I don't see that as a good reason not to fix the problem properly.
  - mixmastamyk 6y ago
    > Meanwhile, the complexity of matching modern Unicode causes performance degradation and exposes many edge cases. As mentioned, there is no way to "fix the problem properly" and a close-enough solution, rarely needed these days, slows performance.

jmgao 6y ago

> More recently, f2fs has started to support this feature as well, following the Ext4 implementation and framework, thanks to an effort led by Google. Most, if not all, of the information described here also applies to f2fs, with small changes on the commands used to configure the superblock. I'd guess that the f2fs changes at least are motivated by sdcard emulation on Android: sdcards were FAT32 in the beginning, so once they started being emulated with a backing store on the regular (ext4, then f2fs on pixels) data partition, case-insensitivity had to be emulated (first via a FUSE daemon in userspace, then via sdcardfs, a stackable FS in the kernel written by Samsung). (I work at Google on Android, but I don't have any first-hand knowledge about this.)