檔案的删除
在前面已經說過如何通過BPB裡的各項參數去找到Data Area，進而得到檔案對應的Directory Entry，最後找到檔案的内容；對于目錄，也是大同小異，不同之處隻是更“曲折”一點，會先找到目錄，去目錄的“内容”裡找到檔案的Directory Entry，進一步，才可以找到檔案内容。那麼，在FAT32裡，檔案如何删除？
實際上非常簡單，FAT32檔案系統在删除檔案的時候，僅僅是對其檔案名進行處理，對于内容是不做任何處理的。對檔案名的處理，就是把其所相關的所有Directory Entry（參考篇二的Long Name Entry）的第一個byte都置為0xE5，此時就認為該檔案已經被删除了。還是用FAT32的image為例來觀察：
首先用dd指令建立一個空的檔案，然後用mkfs.vfat對其格式化，接着挂載到/mnt/目錄，後面建立一個長檔案名的檔案，叫做abcdefghijklmnopqrstuvxwyz.1234567890，裡面的内容是通過“echo "just a test string for this long name file" >> abcdefghijklmnopqrstuvxwyz.1234567890” 完成的。下圖是test.img的内容：
接下來就是把它删除之後的狀态，如下圖：
很容易可以看到，從0x9e000 - 0x9e070一共4個Directory entry的第一個字元都變成0xE5了，而它的檔案内容在0x9e200的地方并沒有任何改變。
目錄的删除
對于檔案的删除是把它相關的directory entry第一個bytes全部置為0xE5，那麼，删除目錄的時候，是不是把目錄相關的directory entry以及它所包含的檔案的directory entry第一個bytes全部置為0xE5呢？以實驗為例
mkdir test
cd /test
touch 1.txt
touch 2.txt
echo 12345 >> 1.txt
echo abcde >> 2.txt
cd ~
umount /mnt/
下圖是以上步驟之後image的内容：
可以看到，test這個目錄仍然是在0x9e000的地方，這是因為之前的檔案已經被删除，是以這裡的空間是可用的，test目錄的内容在簇4，也就是0x9e400，它包括目錄“."，目錄".."，檔案”1.txt"，檔案“2.txt”。接下來就來删除。
下圖是删除test目錄之後，image的内容：
可以看到，确實和預料的一樣，
0x9e000和0x9e020這兩個對應test目錄的directory entry裡，第一個byte都被置為0xE5；
同時，0x9e440和0x9e460這兩個對應1.txt的directory entry第一個byte也被置為0xE5，
0x9e480和0x9e4a0這兩個對應2.txt的directory entry第一個byte也被置為0xE5。
FAT32表的用途
在之前所有的内容裡，都沒有用到FAT32表，那是因為目前為止所有實驗中産生的檔案大小都很小，小于一個簇的大小，還用不到FAT32表。當檔案大小超過一個簇的大小時，從該檔案的directory entry裡能知道該檔案的内容位于哪個簇，那個簇的内容讀完之後，接下來要去哪個簇讀取檔案剩下的内容？此時就需要去FAT32表裡查找。
假設一個檔案的size是3個簇的大小，這個檔案依次放在簇4，5，7裡面。那麼，在簇4所對應的FAT32表項裡，就會填入5；而簇5所對應的FAT32表項裡則會填入7；簇7就已經可以把該檔案剩餘部分全部存放完，不需要再連結到下一個簇，簇7所對應的FAT32表項裡就會填入0xFFFFFFFF，表示EOC（End Of Clusterchain)
FsInfo的作用
目前為止，發現在FsInfo裡最有用的就是offset 0x1EC，FSI_Nxt_Free，用來指明下一個可用的cluster在哪裡。如果沒有這個指針，每次需要存儲新的内容時，都要對整個FAT32進行一次掃描，這樣太浪費時間，沒有效率。在FSI_Nxt_Free的幫助下就可以省卻這個掃描的步驟，直接跳到那個cluster去進行存放。當然，在前面還是要經過一些其他的檢驗，例如size是否足夠，是否有壞簇之類的。