在开源圈中，Linus Torvalds 发火的场面，总能引发一阵“小型地震”。
近日，这位 Linux 之父又一次开炮了——这回，目标直指文件系统开发中的老大难问题：大小写不敏感（case-insensitive，即不区分字符的大小写）。他不仅痛批这种设计是“天大的错误”，连带着 Bcachefs 项目的维护者 Kent Overstreet 也被一通狂怼。
为什么一个看似简单的“大小写问题”会引发 Linus 如此强烈的反应？事情还要从 Bcachefs 最近提交的一个修复补丁说起……
Bcachefs 的修复补丁触发争议
进入正题前，先扫个盲：Bcachefs 是一种用于 Linux 操作系统的写时复制（COW）文件系统，由首席开发者 Kent Overstree 在 2015 年发布。
早在近两年前，来自 Valve/Linux 的一位开发者就曾为 Bcachefs 提交了关于大小写折叠（case folding）/大小写不敏感文件和目录支持的补丁，这一功能随后被合入了 Bcachefs 的内核驱动中。但开发者们发现，这套大小写不敏感机制实际上根本没能正常工作。
为了解决这个长期存在的问题，Bcachefs 开发团队在 Linux 6.15-rc4 发布前夕，提交了新的修复补丁，终于让大小写不敏感的目录支持真正生效。
而在此次提交中，Bcachefs 项目的主开发者 Kent Overstreet 特地附上了一段长篇备注，坦言这次失误背后的深层教训。他提到，当初与负责开发的同事沟通时，虽然提醒过“fstests 套件中应包含相关测试”，但他忽略了强调“必须确保这些测试真正执行过”这一点，从而导致了问题潜伏至今。
Kent Overstreet总结道：
仅仅依赖自动化测试是不够的，你必须亲眼确认自己的代码实际在做什么。也就是说，在你彻底熟悉手头代码和测试套件之前，你需要亲自‘用眼睛看’，确认测试确实按你预期的方式运行，你的代码也确实按你预期的逻辑在执行。
如果你对代码行为还有一丝不确定，就必须主动深入验证——加上 printk 日志、tracepoint 跟踪点、计数器，或者用任何其他手段都可以。自动化测试只是一个兜底机制，并不是万无一失的保障。你一定要在本地运行自己的代码，并亲自观察结果。
jrhz.info仅仅依赖自动化测试是不够的，你必须亲眼确认自己的代码实际在做什么。也就是说，在你彻底熟悉手头代码和测试套件之前，你需要亲自‘用眼睛看’，确认测试确实按你预期的方式运行，你的代码也确实按你预期的逻辑在执行。
如果你对代码行为还有一丝不确定，就必须主动深入验证——加上 printk 日志、tracepoint 跟踪点、计数器，或者用任何其他手段都可以。自动化测试只是一个兜底机制，并不是万无一失的保障。你一定要在本地运行自己的代码，并亲自观察结果。
可以看出，这次 Bcachefs 这次的修复不仅是功能完善，也更像是一次深刻的工程管理反思。
Linus 怒了：大小写不敏感本身就是错误
不过，这件事到了 Linus Torvalds 这里，就不仅仅是测试流程疏忽的问题了——他从更根本的层面，直接对大小写不敏感文件系统的理念发起了猛烈攻击。
在 Linux 内核邮件列表（LKML）上，Linus 写道：“唯一的教训就是：文件系统开发者从来学不会。 大小写不敏感的命名，本身就是天大的错误，根本就不应该去做。问题不是测试做得不够，而是一开始就不该去实现它。”
在 Linus 看来，试图“正确地”实现大小写不敏感，只会导致更多不可控的后果。因为 Unicode 编码标准本身就很复杂，包含了大量的特殊字符、不可打印字符和可忽略字符（ignorable code points），试图在这样一个体系上做到“大小写折叠正确”，几乎是不可能的。
更严重的是，一旦处理得不好，就会引发严重的安全问题。
Linus 举了一个具体的例子：❤ 和 ❤️表面上看非常相似，但实际上是不同的编码。如果大小写折叠逻辑一刀切地忽略这类细节，那么这两个文件名就会被错误地认为是“相同的”——这不仅仅是名字混淆，更会让原本基于字符串检查机制（如验证路径是否安全）的用户空间程序失效，引发安全漏洞。
对于这种潜在风险，Linus 毫不留情地评价：“于是，每一个在用户态中通过文件名检查来保护路径的程序，基本上都能被这种机制骗过，执行了它们明明不该做的操作。 这绝不是小概率事件——有大量程序正是这么工作的。”
在帖子最后，除了点名批评 Bcachefs 项目，Linus 还顺势讽刺了那些怀念老式 FAT 文件系统的人（FAT 文件系统是早期 PC 时代常见的文件系统，但在现代计算环境中，这种设计早已被证明存在大量问题，尤其在安全性和一致性方面表现糟糕）：
真是见鬼了。大小写不敏感，本质上就是个 BUG，文件系统开发者们居然到今天还把它当作一个‘特性’，我完全无法理解。这种行为简直像是，他们对古老的 FAT 文件系统怀有一种变态的崇拜，非得一遍又一遍地把这种糟糕设计复制出来——而且每次都做得更烂。
真是见鬼了。大小写不敏感，本质上就是个 BUG，文件系统开发者们居然到今天还把它当作一个‘特性’，我完全无法理解。这种行为简直像是，他们对古老的 FAT 文件系统怀有一种变态的崇拜，非得一遍又一遍地把这种糟糕设计复制出来——而且每次都做得更烂。
总结来说，在 Linus 看来，所谓“正确实现大小写不敏感”，本质上就是无解的。
开发者对此看法不一
事实上，大小写不敏感文件系统的需求，最早来源于早期 『Windows』（FAT、NTFS）以及 macOS（HFS+）的传统。由于历史兼容性和用户友好性考虑，这些系统允许 File.txt 和 file.TXT 被视为同一个文件。但在 Linux 世界里，从一开始文件系统就是大小写敏感的——File.txt 和 file.txt 是两个完全不同的文件。
近年来，随着跨平台需求增加，部分 Linux 文件系统（如 ext4、F2FS、Btrfs）也陆续引入了可选的大小写不敏感支持。然而正如Linus 所说，盲目追求“兼容”或“方便”，很可能种下难以预料的安全隐患：
（1）性能开销：需要增加更多索引处理逻辑。
（2）标准不统一：Unicode 标准复杂，处理可忽略字符、特殊字符等问题极为棘手。
（3）安全风险：一旦字符串匹配逻辑出现偏差，便可能引发严重的访问控制失效。
对于此次 Linus 的言论，不少开发者表示强烈支持：
“编程的话大小写变量是不同的变量，确实很重要。”
“刚刚遇到一个『Windows』上大小写不敏感的文件覆盖问题，这个的确是设计不合理。”
“真正问题是不统一，因为有的领域区分大小写，有的领域却不区分。当然从字符本身的需求而言，肯定是统一强制区分大小写更省事。”
“编程的话大小写变量是不同的变量，确实很重要。”
“刚刚遇到一个『Windows』上大小写不敏感的文件覆盖问题，这个的确是设计不合理。”
“真正问题是不统一，因为有的领域区分大小写，有的领域却不区分。当然从字符本身的需求而言，肯定是统一强制区分大小写更省事。”
但也 有部分开发者认为，强制区分大小写并不是什么好主意：
“我将继续坚持我对区分大小写的文件系统的厌恶，因为我不得不在 ssh 控制台会话中处理一堆文件，其中每个目录都有数十个文件，这些文件仅在大小写上都有所不同。”
“我将继续坚持我对区分大小写的文件系统的厌恶，因为我不得不在 ssh 控制台会话中处理一堆文件，其中每个目录都有数十个文件，这些文件仅在大小写上都有所不同。”
