Shake Network Technology NewsClick on the right to follow for the latest technology news!
In the open-source community, Linus Torvalds’ outbursts always seem to trigger a wave of “mini earthquakes”. Recently, this father of Linux has once again fired back — this time, targeting a long-standing issue in filesystem development: case insensitivity (i.e., not distinguishing between uppercase and lowercase characters). He not only criticized this design as a “huge mistake” but also lashed out at the maintainer of the Bcachefs project, Kent Overstreet. Why would a seemingly simple “case issue” provoke such a strong reaction from Linus? The story begins with 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 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 ensure these tests are actually executed,” which led to the problem 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 “eyeball” it to confirm that the tests are 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—add printk logs, tracepoint hooks, counters, or use any other means. Automated testing is merely a safety net, not a foolproof guarantee. You must run your code locally and observe the results yourself.
It is clear 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 inherently a mistake
However, when it comes to Linus Torvalds, this issue is not merely 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 that filesystem developers never learn. Case-insensitive naming is 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 is inherently complex, containing numerous special characters, non-printable characters, and ignorable code points; attempting 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 be doing. 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 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 absurd. Case insensitivity is essentially a BUG, and filesystem developers still treat it as a “feature” today; 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, Linus believes that the so-called “correct implementation of case insensitivity” is fundamentally unsolvable.
Developers have mixed opinions on this
In fact, the demand for case-insensitive filesystems 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, 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 needs, some Linux filesystems (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 is required.
(2) Lack of standardization: The Unicode standard is complex, making it extremely tricky to handle ignorable characters, special characters, etc.
(3) Security risks: If the string matching logic deviates, it could 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 easier to enforce case sensitivity uniformly.”
However, some developers believe that enforcing case sensitivity is not a good idea:
-
“I will continue to hold my disdain for 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?
Share
Save
Like
View