NTFS B＋樹大目錄結(jié)構(gòu)動態(tài)解析

吳偉民，劉 凱，江達(dá)強(qiáng)，蘇 慶，陳梓斌

（廣東工業(yè)大學(xué)計(jì)算機(jī)學(xué)院 可視計(jì)算實(shí)驗(yàn)室，廣東 廣州 510006）

0 引 言

NTFS文件系統(tǒng)是隨著Windows NT 操作系統(tǒng)的誕生而產(chǎn)生的，并在隨后的Windows版本中逐漸成為主流的文件系統(tǒng)。NTFS系統(tǒng)具有極其出色的穩(wěn)定性和安全性，在使用過程中不容易產(chǎn)生碎片，同時(shí)它還提供了容錯(cuò)結(jié)構(gòu)日志，在文件系統(tǒng)受到破壞時(shí)，可根據(jù)日志恢復(fù)至一個(gè)一致性的狀態(tài)，此外NTFS還提供了文件壓縮、磁盤配額、利用B＋樹結(jié)構(gòu)來管理文件目錄等功能［1－2］。

NTFS文件系統(tǒng)使用B＋樹結(jié)構(gòu)大目錄對大型文件夾進(jìn)行管理。大目錄結(jié)構(gòu)為三層或三層以上，其中三層目錄結(jié)構(gòu)最為典型。B＋樹大目錄是NTFS優(yōu)于FAT32重要特征之一。分析大目錄的結(jié)構(gòu)和變化規(guī)律是理解NTFS文件系統(tǒng)技術(shù)的重要途徑，也是開發(fā)操作NTFS分區(qū)程序的基礎(chǔ)。Windows操作系統(tǒng)中極其重要的文件夾如Windows、System32、Drivers等都是超大型的目錄?；谏虡I(yè)原因，Mi－crosoft至今沒有完全公布NTFS文件系統(tǒng)技術(shù)資料。國內(nèi)外有比較多的論文論述NTFS結(jié)構(gòu)，如文獻(xiàn)［3－8］對NTFS的主要數(shù)據(jù)結(jié)構(gòu)及應(yīng)用進(jìn)行過分析，但并未涉及目錄結(jié)構(gòu)方面。文獻(xiàn)［9－10］對NTFS的目錄結(jié)構(gòu)做過初步的探索，但是沒有分析過三層大目錄的結(jié)構(gòu)及變化規(guī)律。

本文通過分析NTFS分區(qū)中大目錄產(chǎn)生的原因、結(jié)構(gòu)，通過實(shí)驗(yàn)動態(tài)跟蹤在三層大目錄下創(chuàng)建和刪除文件對大目錄結(jié)構(gòu)產(chǎn)生的影響并得出變化規(guī)律。對于大目錄頻繁操作可能產(chǎn)生的0X20屬性原因和其結(jié)構(gòu)進(jìn)行分析。文章的最后給出改進(jìn)大目錄MFT 文件記錄的方法并進(jìn)行實(shí)驗(yàn)。

1 NTFS重要的數(shù)據(jù)結(jié)構(gòu)簡介

NTFS文件系統(tǒng)由元數(shù)據(jù)（metadata）文件和普通用戶文件組成，元數(shù)據(jù)文件用來文件管理、文件定位、引導(dǎo)程序數(shù)據(jù)、整個(gè)卷分配位圖、錯(cuò)誤恢復(fù)等信息。元數(shù)據(jù)文件除MYMBoot文件外，其他元數(shù)據(jù)文件的位置是可變的［1］。

1.1 MFT文件記錄結(jié)構(gòu)

在NTFS文件系統(tǒng)中，每個(gè)文件（包括元文件）都有一個(gè)或多個(gè)MFT 記錄，大小為1KB。MFT 記錄由記錄頭和一組屬性組成，各個(gè)屬性之間相互獨(dú)立并有各自的類型和名稱。MFT 記錄中屬性如表1［1］所示。

1.2 索引項(xiàng)結(jié)構(gòu)分析

NTFS文件系統(tǒng)中文件夾與它所包含的文件（或文件夾，下同）的關(guān)系是通過索引來建立的，一個(gè)文件夾下文件的索引在父文件夾MFT 記錄的0X90 屬性或數(shù)據(jù)運(yùn)行（DataRun）中，一個(gè)文件夾下所有文件的索引構(gòu)成一個(gè)B＋樹的結(jié)構(gòu)，這種數(shù)據(jù)結(jié)構(gòu)便于快速的查找。索引的排序是按照MYMUpCase元數(shù)據(jù)文件的定義來完成了，而非簡單Unicode編碼［5］。一個(gè)索引包含了自身MFT 參考號、索引的大小、文件的屬性、父目錄的MFT 參考號，文件名等字段。如果該索引在B＋樹結(jié)構(gòu)中為非葉子節(jié)點(diǎn)，最后的增加8Bytes的長度用于保存子節(jié)點(diǎn)索引緩沖區(qū)的VCN號。表2顯示了索引項(xiàng)各字段的含義。

表2 索引項(xiàng)各字段的含義

2 NTFS大目錄結(jié)構(gòu)解析

2.1 產(chǎn)生大目錄的條件

當(dāng)文件夾下的文件較少時(shí)，文件索引直接放在父目錄MFT 記錄的0X90屬性中（長度一般為0X58～0X80Bytes，跟索引的文件名長度相關(guān)）。一個(gè)文件的MFT 記錄大小為1KB，當(dāng)父目錄下的文件不斷增加而生成新的索引項(xiàng)，父目錄MFT 記錄沒有足夠的空間存放時(shí)，會按照B＋樹的節(jié)點(diǎn)分裂規(guī)則進(jìn)行分裂，B＋樹的根節(jié)點(diǎn)保留在父目錄的MFT 記錄中，此時(shí)根節(jié)點(diǎn)中的索引項(xiàng)長度增加8Bytes用來指向其子節(jié)點(diǎn)索引緩沖（VCN）。同時(shí)父目錄MFT 記錄中會添加兩個(gè)屬性0XA0屬性和0XB0屬性，分別用于存放B＋樹的所有子節(jié)點(diǎn)VCN的位置信息和VCN號的分配情況。將分裂出來的索引項(xiàng)存放到VCN 所指向的數(shù)據(jù)運(yùn)行（Data－Run，大小為4KB）中，此時(shí)產(chǎn)生了兩層的B＋目錄結(jié)構(gòu)（文獻(xiàn)［5］圖3提到的三層實(shí)際是二層B＋樹目錄，只是將一個(gè)指向兩層B＋樹的指針放到MFT 記錄中）。當(dāng)文件夾下的文件數(shù)量一直增加，到一個(gè)臨界點(diǎn)，兩層的B＋樹目錄不足以存放所有的索引項(xiàng)時(shí)，B＋樹第二層的一些節(jié)點(diǎn)會根據(jù)B＋樹的分裂規(guī)則分離出葉子節(jié)點(diǎn)，自身成為非葉子節(jié)點(diǎn)，此時(shí)變成了三層B＋樹結(jié)構(gòu)（下文重點(diǎn)分析這種結(jié)構(gòu)）。如果繼續(xù)添加大量的索引項(xiàng)，三層B＋樹的根節(jié)點(diǎn)會膨脹已達(dá)到飽和，三層B＋樹的根節(jié)點(diǎn)在父目錄的MFT 記錄沒有足夠的空間存放，則會在父目錄的MFT 記錄中生成一個(gè)空節(jié)點(diǎn)，原根節(jié)點(diǎn)存放在一個(gè)新的DataRun中，此時(shí)MFT 記錄存放的是一個(gè)指向三層B＋樹結(jié)構(gòu)的指針（Windows 7 中的System32文件夾這種目錄結(jié)構(gòu)比較常見）。

2.2 三級大目錄存放的索引數(shù)目

假設(shè)三級B＋樹大目錄中存放的索引平均長度為0X60Bytes，每個(gè)DataRun 4KB空間存滿的情況下可以存放42個(gè)索引項(xiàng)，這里取B＋樹的階為30，如果三層B＋大目錄樹所有DataRun按照階的限制全部存滿，則每層存放的索引項(xiàng)數(shù)目分別為：

第一層B＋樹存放的索引項(xiàng)數(shù)目：30

第二層B＋樹存放的索引項(xiàng)數(shù)目：30＊30＝900

第三層B＋樹存放的索引項(xiàng)數(shù)目：30＊30＊30＝27000

三層B＋樹存放的索引項(xiàng)總數(shù)：30＋900＋27000＝27930

從上述分析可以，三層B＋樹目錄結(jié)構(gòu)完全能滿足一個(gè)超大型文件夾的下文件數(shù)量的要求。

2.3 三層大目錄結(jié)構(gòu)分析

分析三層大目錄之前，先分析一下0XA0 屬性的數(shù)據(jù)運(yùn)行列表的字段含義和計(jì)算方法。在0XA0屬性偏移0X48處是DataRun列表。每個(gè)DataRun列表的長度不一定相等，但是各個(gè)DataRun列表前后相接，計(jì)算后一個(gè)DataRun列表中的值需要用到前一個(gè)DataRun列表的計(jì)算結(jié)果。

計(jì)算目標(biāo)索引緩沖區(qū)節(jié)點(diǎn)的LCN號，首先要定位到第一個(gè)DataRun列表的位置，讀取該列表的起始LCN和該列表標(biāo)識的索引緩沖區(qū)節(jié)點(diǎn)個(gè)數(shù)（L1），比較目標(biāo)VCN號和L1，如果小于則在目標(biāo)緩沖區(qū)在該列表中，否則查找下一個(gè)列表，后一個(gè)DataRun列表的位置依據(jù)前面的DataRun列表的長度而定，DataRun列表各字段的含義及計(jì)算方法如表3所示。

圖1顯示了一個(gè)DataRun列表在磁盤的物理結(jié)構(gòu)。

根據(jù)表3的計(jì)算方法得出每個(gè)DataRun LCN的結(jié)果，見表4。

判斷索引緩沖區(qū)是不是葉子節(jié)點(diǎn)的依據(jù)是看節(jié)點(diǎn)偏移0X24的值，為1表示非葉子節(jié)點(diǎn)，為0表示葉子節(jié)點(diǎn)。

圖2為Windows XP SP3 系統(tǒng)的System32 大文件夾的三層大目錄結(jié)構(gòu)（不同磁盤上的目錄結(jié)構(gòu)會有差異）。

表3 DataRun列表各字段的含義及計(jì)算方法

圖1 數(shù)據(jù)運(yùn)行列表

表4 DataRun各LCN號

圖2 System32文件夾三層B＋樹結(jié)構(gòu)

2.4 三層大目錄結(jié)構(gòu)變化規(guī)律

在三層B＋樹（m 階）大目錄中創(chuàng)建和刪除文件要進(jìn)行比較復(fù)雜的計(jì)算，可能要調(diào)整B＋樹的結(jié)構(gòu)，會導(dǎo)致操作時(shí)間較長。

2.4.1 刪除文件B＋結(jié)構(gòu)變化規(guī)律

（1）刪除的B＋樹葉子節(jié)點(diǎn)中的一個(gè)索引項(xiàng)，如果刪除后該葉子節(jié)點(diǎn)的關(guān)鍵字個(gè)數(shù)大于等于「m／2」－1，直接刪除索引節(jié)點(diǎn)。如刪除mmc.exe，INDX節(jié)點(diǎn)調(diào)整后如圖3所示。

（2）如果刪除后該葉子節(jié)點(diǎn)的關(guān)鍵字個(gè)數(shù)小于「m／2」－1，會引起B(yǎng)＋樹結(jié)構(gòu)的調(diào)整。按照B＋樹的刪除規(guī)則進(jìn)行變換。如刪除INDX節(jié)點(diǎn)（VCN＝0X0D）中后一半的索引項(xiàng)，將相鄰的葉子節(jié)點(diǎn)的一部分索引移至該節(jié)點(diǎn)，并將節(jié)點(diǎn)的最后一個(gè)索引上移一層并指向該節(jié)點(diǎn)（MPSSVC.dll索引上移一層），B＋樹結(jié)構(gòu)調(diào)整后如圖4所示。

（3）刪除非葉子節(jié)點(diǎn)中的索引項(xiàng)，絕大多數(shù)情況將索引項(xiàng)所指向INDX 節(jié)點(diǎn)中最后一個(gè)索引項(xiàng)替換刪除索引項(xiàng)的位置，刪除索引項(xiàng)的VCN 值不變，如果指向的INDX 也是非葉子節(jié)點(diǎn)，繼續(xù)用下層替換。如下圖中刪除第二層的“索引項(xiàng)21N”和第一層的“索引項(xiàng)23N”B＋樹變化結(jié)果。如圖5所示。

（4）在大目錄中刪除索引項(xiàng)的情況種類繁多，上面列舉最常見的三種。其他種類按照B＋樹節(jié)點(diǎn)中關(guān)鍵的刪除規(guī)則進(jìn)行處理。

2.4.2 添加文件B＋樹變化規(guī)律

在三層大目錄中創(chuàng)建一個(gè)文件（或文件夾）首先根據(jù)父目錄和自身MFT 記錄生成索引項(xiàng)，再從B＋樹根節(jié)點(diǎn)處開始逐層查找合適的插入位置，查找的過程如下。

（1）用待創(chuàng)建文件的文件名（下簡稱待插入項(xiàng)）依次順序和0X90屬性的（或INDX 節(jié)點(diǎn)索引項(xiàng)中的文件名（下簡稱索引項(xiàng)））比較（按照MYMUpCase排序規(guī)則），直到第一次比較大于索引項(xiàng)并使用該索引項(xiàng)中的VCN 查找下一層；如果0X90屬性中只有空索引則使用空索引中的VCN查找下一層。

（2）將查找到的VCN 使用0XA0 屬性中的數(shù)據(jù)運(yùn)行（DataRun）計(jì)算出LCN。

（3）讀出LCN 指向的INDX，查看INDX 是否為葉子節(jié)點(diǎn)，如果是葉子節(jié)點(diǎn)，在INDX 中順序查找第一個(gè)比待插入項(xiàng)大的索引項(xiàng)。此時(shí)待插入項(xiàng)的插入位置在這個(gè)索引項(xiàng)的前面，則查找位置成功。如果是非葉子節(jié)點(diǎn)按照（1）繼續(xù)遞歸進(jìn)行查找。

如果插入索引后葉子節(jié)點(diǎn)的關(guān)鍵字個(gè)數(shù)大于B＋樹的階或者導(dǎo)致INDX 節(jié)點(diǎn)溢出，這時(shí)必須按照B＋樹的分裂規(guī)則進(jìn)行INDX 節(jié)點(diǎn)分裂。

在實(shí)際的創(chuàng)建和刪除文件的操作中，直接對葉子節(jié)點(diǎn)處理耗時(shí)較短，如何對B＋樹結(jié)構(gòu)做大范圍的調(diào)整則耗時(shí)較長，所以在大目錄中創(chuàng)建和刪除文件有時(shí)需要等待一段時(shí)間。

如在System32文件夾下插入文件MicrosoftInsert.txt，結(jié)果如圖6所示。

2.5 大目錄結(jié)構(gòu)下的0X20屬性分析

在三層B＋樹大目錄中很容易產(chǎn)生其他中小型目錄中見不到的0X20 屬性，0X20 屬性是MYMATTRIBUTE＿LIST 屬性，當(dāng)一個(gè)文件的MFT 記錄中有很多屬性或者有些屬性體很大時(shí)就會在主MFT 中生成0X20 屬性，此時(shí)NTFS會給再分配一個(gè)MFT（次）記錄給該文件，用于存放主MFT 記錄存儲不下的屬性。0X20屬性就是用來指標(biāo)哪些屬性在主MFT 記錄中哪些屬性在次MFT 記錄中。

圖6 三層B＋樹結(jié)構(gòu)中插入MicrosoftInsert.txt索引項(xiàng)

0X20屬性很少見，只是在三層B＋樹目錄結(jié)構(gòu)中可能見到，卻是大目錄存在的重要特征。有四種情況可能需要0X20屬性。

（1）文件有很多的硬鏈接（即有很多的文件名屬性存在）。

（2）文件夾下不斷有新的文件產(chǎn)生，產(chǎn)生了很多碎片，一個(gè)MFT 記錄不足以保存下這么多碎片的DataRun。

（3）文件有很復(fù)雜的安全描述符（不適用于NTFS v4.0以上的版本）。

（4）屬性中有很多的命名流。

0X20屬性各字段的含義如表5所示。

表5 0X20屬性各字段含義

0X20出現(xiàn)在一個(gè)文件有多個(gè)MFT 記錄的情況下，它描述了非0X20屬性所屬的MFT。

3 改進(jìn)NTFS大目錄結(jié)構(gòu)

3.1 消除0X20屬性方案

當(dāng)一個(gè)文件產(chǎn)生0X20屬性時(shí)，則說明文件至少具有兩個(gè)MFT 記錄用來存儲常駐屬性。這種特殊的情況給編寫操作NTFS分區(qū)的程序帶來了困難，對多個(gè)MFT 記錄處理會顯著降低NTFS文件系統(tǒng)效率。很有必要對這種結(jié)構(gòu)進(jìn)行改進(jìn)。從分析的結(jié)果看，常常0X20屬性要占用很大的空間0X80～0X120Bytes之間，但是放到第二個(gè)MFT 記錄中的屬性占用的空間不大，常常比0X20屬性的占用的空間少。所以在大多數(shù)情況下0X20屬性是沒有必要的。不清楚為什么Microsoft公司沒有用一種更好的方式處理0X20 屬性。下面提出一種消除0X20 屬性的方法，將一個(gè)文件的兩個(gè)MFT 記錄變成一個(gè)MFT 記錄的方法。

（1）讀MFT 記錄頭部長度字段，跳到0X10屬性開始處，根據(jù)0X10屬性的長度，跳到0X20屬性。

（2）在0X20 屬性，檢索每個(gè)屬性的所在的MFT號，找到次MFT 記錄和其中的屬性組，保存屬性組，計(jì)算屬性組的長度；計(jì)算主MFT 記錄最大可用空間，0X400－主MFT 記錄的實(shí)際長度＋0X20 屬性的長度。如果屬性組長度小于等于最大可用空間，則下一步，否則退出。

（3）讀取0X20屬性的后面的所有屬性并保存。

（4）消除MFT 記錄更新序列號，將主MFT 記錄中的0X20屬性后面的屬性組與次MFT 記錄的屬性組依次比較屬性類型，按照大小從0X20開始處存放。

（5）所有屬性在主MFT 記錄中存放完畢后，在最后加上0XFFFFFFFF結(jié)束標(biāo)識。

（6）更新主MFT 記錄偏移0X18 處的MFT 記錄實(shí)際長度字段。值更新為：原MFT 實(shí)際長度－0X20屬性長度＋次MFT 記錄中屬性組的長度。

（7）寫回更新序列號：將主MFT 記錄的第一、第二個(gè)扇區(qū)的最后兩個(gè)字節(jié)分別到0X32～0X35 偏移處的更新數(shù)組處，再將0X30～0X31的更新序列號寫到MFT 記錄的第一和第二個(gè)扇區(qū)的最后兩個(gè)字節(jié)。主MFT 記錄修改完畢。

（8）添加刪除標(biāo)志：將次MFT 記錄的0X16處的刪除標(biāo)志更新為0X00（MFT 被刪除）或0X02（目錄被刪除）。

（9）根據(jù)次MFT 記錄的MFT號，在MYMMFT：BitMap中找到對應(yīng)的位，將1更新為0，表示次MFT 記錄刪除。流程圖如圖7所示、實(shí)驗(yàn)結(jié)果圖8所示。

隨著系統(tǒng)的使用不斷會有新的應(yīng)用程序安裝，在系統(tǒng)文件夾（Windows、System32 等）產(chǎn)生新的文件。這些文件夾下的文件數(shù)量不斷的增加，每過一段時(shí)間就會分配一個(gè)新的索引緩沖區(qū)用于存放。這樣很容易產(chǎn)生緩沖區(qū)碎片，影響系統(tǒng)的性能。在每次生成新的索引緩沖區(qū)節(jié)點(diǎn)時(shí)，如果前面有比較多的碎片，可以將前面的碎片合并成一個(gè)大塊的緩沖區(qū)組，便于提升系統(tǒng)的性能。

圖7 操作合并MFT 記錄流程

圖8 合并MFT 記錄的實(shí)驗(yàn)操作結(jié)果

3.2 大目錄優(yōu)化效果

消除System32文件夾0X20屬性并合并分散的數(shù)據(jù)運(yùn)行。實(shí)驗(yàn)室硬件設(shè)備Lenovo楊天M4600N，Windows XP SP3系統(tǒng)。使用自制小工具使用自制小工具ReadBigDirectory讀取System32文件夾下所有文件的文件名，為了確保測試精度，時(shí)間使用64位的Windows文件時(shí)間（UTC 格式），以100毫微秒為間隔的間隔數(shù)。工具核心代碼為：

DateTime startTime＝DateTime.Now；

string path＝txtDirectory.Text；

string［］fileNames＝Directory.GetFiles（path，" ＊.＊"，SearchOption.TopDirectoryOnly）；

DateTime endTime＝DateTime.Now；

圖9 程序運(yùn)行界面

由于Windows會緩存已操作過的結(jié)果，每次系統(tǒng)重新啟動第一次運(yùn)行測試程序結(jié)果有效。對目錄優(yōu)化前后分別做5次數(shù)據(jù)采集，取平均值，結(jié)果如表6所示（單位毫秒）。

表6 優(yōu)化前后操作大目錄時(shí)間

優(yōu)化前后的對比結(jié)果可以看出，查找System32文件下所有文件的時(shí)間縮短了19.389毫秒，優(yōu)化后有較好的效果。

4 結(jié)束語

NTFS B＋樹大目錄數(shù)據(jù)結(jié)構(gòu)復(fù)雜，是理解NFTS文件系統(tǒng)目錄管理的難點(diǎn)，也是設(shè)計(jì)NTFS文件系統(tǒng)操作程序的關(guān)鍵。本文詳細(xì)地分析三層B＋樹大目錄產(chǎn)生的原因、結(jié)構(gòu)和動態(tài)變化規(guī)律，在此基礎(chǔ)上分析大目錄中可能會產(chǎn)生的0X20屬性結(jié)構(gòu)，并提出改進(jìn)有0X20屬性MFT記錄的方法。

最后實(shí)驗(yàn)驗(yàn)證了對NTFS大目錄的分析結(jié)果。該分析結(jié)果為開發(fā)操作NTFS 文件系統(tǒng)的程序提供了理論支持。同時(shí)提出改進(jìn)NTFS文件系統(tǒng)效率的方法。

［1］Microsoft TechNet.Optimizing NTFS［EB／OL］.［2011－12－08］.http：／／technet.microsoft.com／en－us／library／cc767961.aspx，2010.

［2］Carrier B.File system forensic analysis［M］.Pearson Education，Inc，2009：369－380.

［3］ZHANG Kai.Analysis and implementation of NTFS file system based on computer forensics［C］／／ETCS，2010：325－328.

［4］Huebner E，Bem D，Wee C K.Data hiding in the NTFS file system［J］.Digital Investigation，2006，3（4）：211－226.

［5］WANG Lina，YANG Mo.Computer forensics research and implementation based on NTFS file system［J］.Journal－Wuhan University Natural Sciences Edition，2006，52（5）：519.

［6］WANG Lanying，JU Jinwu.Analysis of NTFS file system structural［J］.Computer Engineering and Design，2006，27（3）：418－420（in Chinese）.［王蘭英，居錦武.NTFS文件系統(tǒng)結(jié)構(gòu)分析［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2006，27（3）：418－420.］

［7］JU Jinwu，WANG Lanying.Analysis of NTFS file system［J］.Computer Engineering and Design，2007，28（22）：5437－5460（in Chinese）.［居錦武，王蘭英.NTFS文件系統(tǒng)剖析［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2007，28（22）：5437－5460.］

［8］ZHAO Shuangfeng，F(xiàn)EI Jinlong，LIU Nan，et al.Research and implementation of data recovery on Windows NTFS［J］.Computer Engineering and Design，2008，29（2）：306－308（in Chinese）.［趙雙峰，費(fèi)金龍，劉楠，等.Windows NTFS下數(shù)據(jù)恢復(fù)的研究與實(shí)現(xiàn)［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2008，29（2）：306－308.］

［9］WU Weimin，LU Qi，WANG Zhenhua，et al.Dynamic analysis of B＋tree structure of index in NTFS directory［J］.Computer Engineering and Design，2010（22）：4843－4846（in Chinese）.［吳偉民，盧琦，王振華，等.NTFS目錄下索引B＋樹結(jié)構(gòu)動態(tài)解析［J］.計(jì)算機(jī)工程與設(shè)計(jì)，2010（22）：4843－4846.］

［10］Faraz Ahsan，Ikram Lali M.Exploring the effect of directory depth on file access for FAT and NTFS file systems［C］／／ISTASC，2008：130－135.