在建立乙個空的新檔案的時候，
寫資料時，fsd會在cache中判斷寫的資料offset +len =len1是不是比原來的size大，如果是，則會把這個offset +len更新下去
這時候，後面來乙個no cache的寫的時候，由於這時的寫必須是加密後的，offset+len=len2肯定會比上面的len1大。
fsd在no cache寫的時候，發現len2比len1大，那fsd只會把len1的長度寫下去，而len2-len1這個大小就會被漏掉
ps:正在做的加密演算法是明文4k對應密文8k
所以要在cache write 的時候也要更新這個大小。但這時候又有乙個問題，是在cache write 前更新還是cache write 後更新呢
1。如果是在cache write 後更新，則有乙個問題,考慮如下情形。
在cache write pre 寫5個的時候，我們不干涉這個操作，而在post裡面再更新，在fsd在呼叫我們的cache write post 之前，這時候突然來乙個no cache write.（一般是由系統的定時器發起的乙個nocache lazy write）
這時候有可能fsd已經把這5個位元組大小更新到fcb中去了，此時no cache write ，改成加密後的資料大小的話就是len2=8k個位元組，
那這樣就出現上面提及的問題。fsd在執行這個no cache write的時候，發現8k比5個位元組大，最後寫的時候僅寫了這5個位元組。問題嚴重！
2。如果是在cache write pre 前更新。
會導致這樣的乙個問題，在攔截到cache write操作write 5個位元組的時候。如果fcb->size==0，我們更新為0x1000時，會導致這樣：
fsd發現檔案的大小為0x1000，就會發乙個no cache去讀檔案到快取中，以滿足這個write操作。但其實這時，那個檔案其實根本就沒大小的，讀出來的內容當做密文使用的話就會出現問題
最後解決方法是採用1的，但是在no cache write的時候，需要是手工update fcb裡面的位元組大小
檔案透明加解密的實現層次
王永龍 檔案透明加解密是最近幾年發展出來的一種檔案加解密技術。所謂透明，是指在加解密的時候，使用者是完全感覺不到的，作為使用者，開啟檔案，關閉檔案，讀寫檔案都跟正常的無異，但實際上系統在底層處理的時候，已經做了加解密的處理，在使用者讀取檔案時，系統將檔案解密後放入記憶體中供使用者使用，使用者檔案儲存...
檔案過濾驅動，如何動態透明加解密？
檔案過濾驅動是微軟公開支援進行檔案加密的技術手段，在驅動的層次定義中，微軟定義了防毒 壓縮 加密等各種功能層次，加密的定義如下 load order group fsfilter encryption altitude range 140000 149999 由於檔案過濾驅動處於驅動層面 不像api...
加解密方法
imports system imports system.security.cryptography imports system.text imports system.io public class encryptor private shared iv as byte private sha...