做伪透明加解密时，文件大小不一维护

在创建一个空的新文件的时候，

写数据时，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里面的字节大小