Compiled by | Zheng LiyuanProduced by | CSDN (ID: CSDNnews)
In the open-source community, Linus Torvalds’ outbursts often trigger a wave of “mini-earthquakes”.
Recently, the father of Linux has once again fired back — this time targeting a long-standing issue in file system development: case insensitivity (i.e., not distinguishing 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) file system 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 to support case folding/case-insensitive files and directories, 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 included a lengthy note, admitting the deeper lessons behind this oversight. He mentioned that while he had reminded his colleagues that “the fstests suite should include relevant tests,” he neglected to emphasize that “it must be ensured that these tests are actually executed,” which allowed the problem to persist until now.
Kent Overstreet summarized:
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 actively verify it — add printk logs, tracepoint markers, counters, or use 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 clear that this Bcachefs fix is not just about functionality improvement; it 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 not merely about testing process negligence — he launched a fierce attack on the very concept of case-insensitive file systems from a more fundamental level.
On the Linux Kernel Mailing List (LKML), Linus wrote: “The only lesson is that file system developers never learn. Case-insensitive naming is a huge mistake that should never have been implemented. 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 well, it can lead to severe security issues.
Linus provided a specific example:❤ and ❤️ appear very similar, but they are actually different encodings. If the case folding logic blindly ignores such details, 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 that protects paths through filename checks in user space can essentially be fooled by this mechanism, executing operations it should not perform. This is not a rare event — many programs work this way.”
At the end of the post, in addition to criticizing the Bcachefs project, Linus also sarcastically mocked those who long for the old FAT file system (the FAT file system was common in the early PC era, but in modern computing environments, this design has proven to have numerous issues, especially in terms of security and consistency):
It’s truly ridiculous. Case insensitivity is essentially a BUG, and file system developers still treat it as a ‘feature’ to this day; I simply cannot understand this behavior. It’s as if they have a perverse admiration for the old FAT file system, insisting on replicating this poor design over and over again — and each time doing it worse.
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 file systems originated from the traditions of early Windows (FAT, NTFS) and macOS (HFS+) due to historical compatibility and user-friendliness considerations, allowing File.txt and file.TXT to be treated as the same file. However, in the Linux world, file systems 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 needs, some Linux file systems (such as ext4, F2FS, Btrfs) have gradually introduced optional case-insensitive support. However, as Linus mentioned, blindly pursuing “compatibility” or “convenience” can easily 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, as some fields 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 file systems because 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 file systems 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?
Reference links:
https://www.phoronix.com/news/Linus-Torvalds-Anti-Case-Fold
https://www.phoronix.com/news/Bcachefs-Linux-6.15-Fixes-Fold
Recommended Reading:▶Microsoft accused of “copying” personal project, developer claims: large sections of code were lifted, I was only thanked in the README!▶“What a loss! I spent over 3000 yuan using Claude to make a game, and it would have been better to ‘get it for free’ with Gemini 2.5…”▶Just modifying 30 lines of Linux code saved 30% power? The University of Waterloo team’s “magic patch” has been merged into Linux 6.13!