In the open-source community, Linus Torvalds’ outbursts always seem to trigger a “small earthquake”.Recently, the father of Linux has once again fired back— this time, targeting a long-standing issue in filesystem development: case insensitivity (case-insensitive, meaning it does not distinguish between uppercase and lowercase characters). He not only criticized this design as a “huge mistake,” but also took aim at the maintainer of the Bcachefs project, Kent Overstreet. Why would a seemingly simple “case issue” provoke such a strong reaction from Linus? The matter traces back to a recent patch submitted for Bcachefs…
The Bcachefs patch triggered controversy
Before diving into the main topic, let’s clarify: Bcachefs is a copy-on-write (COW) filesystem for the Linux operating system, released by chief developer Kent Overstreet in 2015.
Nearly two years ago, a developer from Valve/Linux submitted a patch for Bcachefs regarding case folding/case-insensitive file and directory support, which was subsequently merged into the Bcachefs kernel driver. However, developers found that this case-insensitive mechanism did not work properly.
To address this long-standing issue, the Bcachefs development team submitted a new patch just before the release of Linux 6.15-rc4, finally enabling proper support for case-insensitive directories.
In this submission, Kent Overstreet, the main developer of Bcachefs, included a lengthy note, admitting the deeper lessons behind this oversight. He mentioned that during discussions with the colleague responsible for development, he had reminded them that “the fstests suite should include relevant tests,” but he neglected to emphasize that “it must ensure these tests are actually executed,” which led to the issue persisting until now.
Kent Overstreet concluded:
Relying solely on automated testing is not enough; you must verify what your code is actually doing with your own eyes. In other words, before you are thoroughly familiar with the code and test suite at hand, you need to personally “look with your eyes” to confirm that the tests are indeed running as you expect and that your code is executing according to your intended logic.
If you have any uncertainty about the behavior of the code, you must proactively verify it—adding printk logs, tracepoint markers, counters, or using any other means. Automated testing is merely a fallback mechanism, not a foolproof guarantee. You must run your code locally and observe the results yourself.
It is evident that this Bcachefs fix is not only about functionality but also serves as a profound reflection on engineering management.
Linus is angry: Case insensitivity is fundamentally a mistake
However, when it reached Linus Torvalds, this issue was no longer just about testing process negligence— he launched a fierce attack on the very concept of case-insensitive filesystems from a more fundamental level.
On the Linux Kernel Mailing List (LKML), Linus wrote: “The only lesson is: filesystem developers never learn. Case-insensitive naming is fundamentally a huge mistake that should never have been done. The problem is not that testing was insufficient, but that it should never have been implemented in the first place.”
In Linus’s view, attempting to “correctly” implement case insensitivity will only lead to more uncontrollable consequences. This is because the Unicode encoding standard itself is very complex, containing a large number of special characters, non-printable characters, and ignorable code points; trying to achieve “correct case folding” within such a system is nearly impossible.
More seriously, if not handled properly, it can lead to severe security issues.
Linus provided a specific example:❤ and ❤️ may appear very similar, but they are actually different encodings. If the case folding logic blindly ignores such details, then these two filenames could be incorrectly considered “the same”— this is not just a name confusion; it could cause user-space programs that rely on string-checking mechanisms (such as verifying whether a path is safe) to fail, leading to security vulnerabilities.
Regarding this potential risk, Linus harshly commented:“Thus, every program in user space that protects paths through filename checks can essentially be fooled by this mechanism, executing operations they should not perform. This is not a rare occurrence—many programs operate this way.”
At the end of the post, in addition to criticizing the Bcachefs project, Linus also took the opportunity to mock those who reminisce about the old FAT filesystem (the FAT filesystem was a common filesystem in the early PC era, but in modern computing environments, this design has been proven to have numerous issues, especially in terms of security and consistency):
It’s truly absurd. Case insensitivity is essentially a BUG, and filesystem developers still treat it as a ‘feature’ to this day; I simply cannot understand this. This behavior is akin to a perverse admiration for the old FAT filesystem, as if they must repeatedly replicate this poor design—only to do it worse each time.
In summary, in Linus’s view, the so-called “correct implementation of case insensitivity” is fundamentally unsolvable.
Developers have mixed opinions on this view
In fact, the demand for case-insensitive filesystems originated from the traditions of early Windows (FAT, NTFS) and macOS (HFS+) systems. For historical compatibility and user-friendliness, these systems allow File.txt and file.TXT to be treated as the same file. However, in the Linux world, filesystems have always been case-sensitive from the start—File.txt and file.txt are two completely different files.
In recent years, with the increase in cross-platform demands, some Linux filesystems (such as ext4, F2FS, Btrfs) have gradually introduced optional case-insensitive support. However, as Linus mentioned, blindly pursuing “compatibility” or “convenience” may sow the seeds of unpredictable security risks:
(1) Performance overhead: More indexing processing logic needs to be added.
(2) Lack of standardization: The Unicode standard is complex, and handling ignorable characters, special characters, etc., is extremely tricky.
(3) Security risks: If the string matching logic deviates, it may lead to severe access control failures.
Regarding Linus’s remarks, many developers expressed strong support:
-
“In programming, case-sensitive variables are indeed different variables, which is very important.”
-
“I just encountered a case-insensitive file overwrite issue on Windows; this is indeed an unreasonable design.”
-
“ The real problem is inconsistency, because some areas distinguish case while others do not. Of course, from the perspective of character requirements, it is certainly more convenient to enforce case sensitivity.”
However, some developers believe that enforcing case sensitivity is not a good idea:
-
“ I will continue to maintain my aversion to case-sensitive filesystems, as I have to deal with a bunch of files in ssh console sessions, where each directory has dozens of files that differ only in case.
-
“ I completely disagree with Linus’s viewpoint and anger. In my opinion, case-sensitive filesystems have always been a foolish retrogressive idea, and no one can provide a reason for needing it.”
So, what are your thoughts on this matter?