最近研究寫(xiě)NTFS驅(qū)動(dòng)下的讀寫(xiě)壓縮/稀疏文件功能的時(shí)候被微軟雷到了。

真不愧“微軟讓事情變得復(fù)雜 (Microsoft make things complicated)”的傳聞。

壓縮/占位流描述組居然可以分別存放到兩個(gè)屬性中.......徹底囧掉了......為了省幾個(gè)字節(jié)的空間，代碼復(fù)雜度起碼提高一個(gè)數(shù)量級(jí)，犯得上么.......

?

然后又發(fā)現(xiàn)一個(gè)更囧的情況：NTFS屬性中的流可以被任意拆開(kāi)描述，一個(gè)10個(gè)簇長(zhǎng)的流可以被寫(xiě)成10個(gè)1個(gè)簇的流！

比如：

11 08 10

LCN 10,LENGTH 08

完成可以被改成：

11 01 10 11 01 01 11 01 01 11 01 01 11 01 01 11 01 01 11 01 01 11 01 01

?

-_-b

?

也就是說(shuō)，16個(gè)簇的壓縮單元可能被寫(xiě)成16個(gè)流的描述，而不受壓縮單元尺寸限制的稀疏文件，則存在無(wú)限可能......

而且還都能通過(guò)CHKDSK的檢查并能被WINDOWS正常訪問(wèn)。

更可悲的是：這些流可能被拆開(kāi)存放于多個(gè)屬性中......雖然WINDOWS自身并不會(huì)這樣做，但只要這是合法的，那別的程序就只能無(wú)條件的支持......

?

綜上。非常簡(jiǎn)單的壓縮/稀疏文件操作邏輯，理論上有演變成無(wú)聊，復(fù)雜，效率低下的多屬性下流描述的修改操作的可能，而且事實(shí)上，程序必須處理此種狀況。代碼復(fù)雜度因?yàn)檫@個(gè)小小的設(shè)計(jì)巨增。

?

?

勞資痛恨微軟那幫BT！