整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

在開源圈中，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 跟蹤點、計數器，或者用任何其他手段都可以。自動化測試只是一個兜底機制，并不是萬無一失的保障。你一定要在本地運行自己的代碼，并親自觀察結果。

可以看出，這次 Bcachefs 這次的修復不僅是功能完善，也更像是一次深刻的工程管理反思。

Linus 怒了：大小寫不敏感本身就是錯誤

不過，這件事到了 Linus Torvalds 這里，就不僅僅是測試流程疏忽的問題了——他從更根本的層面，直接對大小寫不敏感文件系統的理念發起了猛烈攻擊。

在 Linux 內核郵件列表（LKML）上，Linus 寫道：“唯一的教訓就是：文件系統開發者從來學不會。大小寫不敏感的命名，本身就是天大的錯誤，根本就不應該去做。問題不是測試做得不夠，而是一開始就不該去實現它。”

在 Linus 看來，試圖“正確地”實現大小寫不敏感，只會導致更多不可控的后果。因為 Unicode 編碼標準本身就很復雜，包含了大量的特殊字符、不可打印字符和可忽略字符（ignorable code points），試圖在這樣一個體系上做到“大小寫折疊正確”，幾乎是不可能的。

更嚴重的是，一旦處理得不好，就會引發嚴重的安全問題。

Linus 舉了一個具體的例子：? 和 ??表面上看非常相似，但實際上是不同的編碼。如果大小寫折疊邏輯一刀切地忽略這類細節，那么這兩個文件名就會被錯誤地認為是“相同的”——這不僅僅是名字混淆，更會讓原本基于字符串檢查機制（如驗證路徑是否安全）的用戶空間程序失效，引發安全漏洞。

對于這種潛在風險，Linus 毫不留情地評價：“于是，每一個在用戶態中通過文件名檢查來保護路徑的程序，基本上都能被這種機制騙過，執行了它們明明不該做的操作。這絕不是小概率事件——有大量程序正是這么工作的。”

在帖子最后，除了點名批評 Bcachefs 項目，Linus 還順勢諷刺了那些懷念老式 FAT 文件系統的人（FAT 文件系統是早期 PC 時代常見的文件系統，但在現代計算環境中，這種設計早已被證明存在大量問題，尤其在安全性和一致性方面表現糟糕）：

真是見鬼了。大小寫不敏感，本質上就是個 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上大小寫不敏感的文件覆蓋問題，這個的確是設計不合理。”

• “真正問題是不統一，因為有的領域區分大小寫，有的領域卻不區分。當然從字符本身的需求而言，肯定是統一強制區分大小寫更省事。”

但也有部分開發者認為，強制區分大小寫并不是什么好主意：

• “我將繼續堅持我對區分大小寫的文件系統的厭惡，因為我不得不在 ssh 控制臺會話中處理一堆文件，其中每個目錄都有數十個文件，這些文件僅在大小寫上都有所不同。”

• “我完全不同意 Linus 的觀點和憤怒。在我看來，區分大小寫的文件系統一直是個愚蠢的倒退想法，沒有一個人能給出他們需要它的理由。”

那么對于這個事情，你的看法又是如何呢？

https://www.phoronix.com/news/Linus-Torvalds-Anti-Case-Fold

https://www.phoronix.com/news/Bcachefs-Linux-6.15-Fixes-Fold