加密时如果改变文件长度，具体会有什么麻烦？

在驱网上我也搜索了一下，但是没有搜到什么具体的信息。
个人感觉麻烦肯定会有的。但是能不能想办法去克服呢？

由于我还没有具体接触，想请哪位大虾具体解说一个麻烦之处，
这样我可以思考一下。 :)

你的帮助对我很重要！

en,我估计这条路不好走哇！放弃！

我也关注。在OSR上看说确实很复杂，也没有见人实现。

真的麻烦，我前段时间试验过了，正如你所想做的那样，在受控的文件前面增加一个加密标志，然后我们驱动程序读取的时候识别它，决定是否加解密。而这个标志对应用层是完全透明的。

实现的过程中成功添加了加密标志，但文件长度发生变化，于是我尝试过在IRP_MJ_GET_INFORMATION中修改文件的长度，可是系统仍然能够获得正确的文件长度信息，试了试修改FCB中的文件长度信息，这样可以成功的隐藏文件长度，但又出现了其它的问题，所以后来彻底放弃了这个想法。

Basically I think you have to answer two simple questions first:
1. When does file system change file size?
2. How does file system change file size?

File size can be changed in several IRPs. For example, MJ_CREATE can truncate a file, MJ_WRITE can extend a file. Beside these anybody ever thinks of how to deal with compressed files and sparse files in NTFS? Also file size change for remote files introduce more difficulties since redirector is involved in file sharing.

Personally I think the reason why file size change is so difficult to deal with is because Windows file system and its filter drivers sharing the same system cache. On LINUX, stackable file systems have their own cache. A file system can do whatever it wants and won\'t affect file systems below it. On Windows everything is tightly coupled. Though I like a lot of features of Windows and NTFS, but I don\'t like the design here.

It is 麻烦 and 复杂. :(

我发现对与DOC文档，如果通过改变文件长度来加密的话，则DOC文件就不能解密了