整理 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
在開源圈中，Linus Torvalds 發(fā)火的場面，總能引發(fā)一陣“小型地震”。
近日，這位 Linux 之父又一次開炮了——這回，目標(biāo)直指文件系統(tǒng)開發(fā)中的老大難問題：大小寫不敏感（case-insensitive，即不區(qū)分字符的大小寫）。他不僅痛批這種設(shè)計是“天大的錯誤”，連帶著 Bcachefs 項目的維護(hù)者 Kent Overstreet 也被一通狂懟。
為什么一個看似簡單的“大小寫問題”會引發(fā) Linus 如此強(qiáng)烈的反應(yīng)？事情還要從 Bcachefs 最近提交的一個修復(fù)補丁說起……
Bcachefs 的修復(fù)補丁觸發(fā)爭議
進(jìn)入正題前，先掃個盲：Bcachefs 是一種用于 Linux 操作系統(tǒng)的寫時復(fù)制（COW）文件系統(tǒng)，由首席開發(fā)者 Kent Overstree 在 2015 年發(fā)布。
早在近兩年前，來自 Valve/Linux 的一位開發(fā)者就曾為 Bcachefs 提交了關(guān)于大小寫折疊（case folding）/大小寫不敏感文件和目錄支持的補丁，這一功能隨后被合入了 Bcachefs 的內(nèi)核驅(qū)動中。但開發(fā)者們發(fā)現(xiàn)，這套大小寫不敏感機(jī)制實際上根本沒能正常工作。
為了解決這個長期存在的問題，Bcachefs 開發(fā)團(tuán)隊在 Linux 6.15-rc4 發(fā)布前夕，提交了新的修復(fù)補丁，終于讓大小寫不敏感的目錄支持真正生效。
而在此次提交中，Bcachefs 項目的主開發(fā)者 Kent Overstreet 特地附上了一段長篇備注，坦言這次失誤背后的深層教訓(xùn)。他提到，當(dāng)初與負(fù)責(zé)開發(fā)的同事溝通時，雖然提醒過“fstests 套件中應(yīng)包含相關(guān)測試”，但他忽略了強(qiáng)調(diào)“必須確保這些測試真正執(zhí)行過”這一點，從而導(dǎo)致了問題潛伏至今。
Kent Overstreet 總結(jié)道：
僅僅依賴自動化測試是不夠的，你必須親眼確認(rèn)自己的代碼實際在做什么。也就是說，在你徹底熟悉手頭代碼和測試套件之前，你需要親自‘用眼睛看’，確認(rèn)測試確實按你預(yù)期的方式運行，你的代碼也確實按你預(yù)期的邏輯在執(zhí)行。 如果你對代碼行為還有一絲不確定，就必須主動深入驗證——加上 printk 日志、tracepoint 跟蹤點、計數(shù)器，或者用任何其他手段都可以。自動化測試只是一個兜底機(jī)制，并不是萬無一失的保障。你一定要在本地運行自己的代碼，并親自觀察結(jié)果。
可以看出，這次 Bcachefs 這次的修復(fù)不僅是功能完善，也更像是一次深刻的工程管理反思。
Linus 怒了：大小寫不敏感本身就是錯誤
不過，這件事到了 Linus Torvalds 這里，就不僅僅是測試流程疏忽的問題了——他從更根本的層面，直接對大小寫不敏感文件系統(tǒng)的理念發(fā)起了猛烈攻擊。
在 Linux 內(nèi)核郵件列表（LKML）上，Linus 寫道：“唯一的教訓(xùn)就是：文件系統(tǒng)開發(fā)者從來學(xué)不會。大小寫不敏感的命名，本身就是天大的錯誤，根本就不應(yīng)該去做。問題不是測試做得不夠，而是一開始就不該去實現(xiàn)它。”
在 Linus 看來，試圖“正確地”實現(xiàn)大小寫不敏感，只會導(dǎo)致更多不可控的后果。因為 Unicode 編碼標(biāo)準(zhǔn)本身就很復(fù)雜，包含了大量的特殊字符、不可打印字符和可忽略字符（ignorable code points），試圖在這樣一個體系上做到“大小寫折疊正確”，幾乎是不可能的。
更嚴(yán)重的是，一旦處理得不好，就會引發(fā)嚴(yán)重的安全問題。
Linus 舉了一個具體的例子：? 和 ??表面上看非常相似，但實際上是不同的編碼。如果大小寫折疊邏輯一刀切地忽略這類細(xì)節(jié)，那么這兩個文件名就會被錯誤地認(rèn)為是“相同的”——這不僅僅是名字混淆，更會讓原本基于字符串檢查機(jī)制（如驗證路徑是否安全）的用戶空間程序失效，引發(fā)安全漏洞。
對于這種潛在風(fēng)險，Linus 毫不留情地評價：“于是，每一個在用戶態(tài)中通過文件名檢查來保護(hù)路徑的程序，基本上都能被這種機(jī)制騙過，執(zhí)行了它們明明不該做的操作。這絕不是小概率事件——有大量程序正是這么工作的。”
在帖子最后，除了點名批評 Bcachefs 項目，Linus 還順勢諷刺了那些懷念老式 FAT 文件系統(tǒng)的人（FAT 文件系統(tǒng)是早期 PC 時代常見的文件系統(tǒng)，但在現(xiàn)代計算環(huán)境中，這種設(shè)計早已被證明存在大量問題，尤其在安全性和一致性方面表現(xiàn)糟糕）：
真是見鬼了。大小寫不敏感，本質(zhì)上就是個 BUG，文件系統(tǒng)開發(fā)者們居然到今天還把它當(dāng)作一個‘特性’，我完全無法理解。這種行為簡直像是，他們對古老的 FAT 文件系統(tǒng)懷有一種變態(tài)的崇拜，非得一遍又一遍地把這種糟糕設(shè)計復(fù)制出來——而且每次都做得更爛。
總結(jié)來說，在 Linus 看來，所謂“正確實現(xiàn)大小寫不敏感”，本質(zhì)上就是無解的。
開發(fā)者對此看法不一
事實上，大小寫不敏感文件系統(tǒng)的需求，最早來源于早期 Windows（FAT、NTFS）以及 macOS（HFS+）的傳統(tǒng)。由于歷史兼容性和用戶友好性考慮，這些系統(tǒng)允許 File.txt 和 file.TXT 被視為同一個文件。但在 Linux 世界里，從一開始文件系統(tǒng)就是大小寫敏感的——File.txt 和 file.txt 是兩個完全不同的文件。
近年來，隨著跨平臺需求增加，部分 Linux 文件系統(tǒng)（如 ext4、F2FS、Btrfs）也陸續(xù)引入了可選的大小寫不敏感支持。然而正如 Linus 所說，盲目追求“兼容”或“方便”，很可能種下難以預(yù)料的安全隱患：
（1）性能開銷：需要增加更多索引處理邏輯。
（2）標(biāo)準(zhǔn)不統(tǒng)一：Unicode 標(biāo)準(zhǔn)復(fù)雜，處理可忽略字符、特殊字符等問題極為棘手。
（3）安全風(fēng)險：一旦字符串匹配邏輯出現(xiàn)偏差，便可能引發(fā)嚴(yán)重的訪問控制失效。
對于此次 Linus 的言論，不少開發(fā)者表示強(qiáng)烈支持：
“編程的話大小寫變量是不同的變量，確實很重要?！?/p>
“剛剛遇到一個Windows上大小寫不敏感的文件覆蓋問題，這個的確是設(shè)計不合理。”
“真正問題是不統(tǒng)一，因為有的領(lǐng)域區(qū)分大小寫，有的領(lǐng)域卻不區(qū)分。當(dāng)然從字符本身的需求而言，肯定是統(tǒng)一強(qiáng)制區(qū)分大小寫更省事?！?/p>
但也有部分開發(fā)者認(rèn)為，強(qiáng)制區(qū)分大小寫并不是什么好主意：
“我將繼續(xù)堅持我對區(qū)分大小寫的文件系統(tǒng)的厭惡，因為我不得不在 ssh 控制臺會話中處理一堆文件，其中每個目錄都有數(shù)十個文件，這些文件僅在大小寫上都有所不同。”
“我完全不同意 Linus 的觀點和憤怒。在我看來，區(qū)分大小寫的文件系統(tǒng)一直是個愚蠢的倒退想法，沒有一個人能給出他們需要它的理由?！?/p>
那么對于這個事情，你的看法又是如何呢？
https://www.phoronix.com/news/Linus-Torvalds-Anti-Case-Fold
https://www.phoronix.com/news/Bcachefs-Linux-6.15-Fixes-Fold
熱門跟貼