tooflat的加密代码中SfIssueReadWriteIrpSynchronously函数有误？

  加密过程：
FileCtxPtr->DecryptOnRead = FALSE;//明文读
FileCtxPtr->EncryptOnWrite = TRUE;//密文写
Status = SfEncryptDecryptFileByFileObject(DeviceObject, FileObject);

但在具体SfEncryptDecryptFileByFileObject中传递给SfIssueReadWriteIrpSynchronously函数的irpflgs参数始终是0；因此IoBuildSynchronousFsdRequest建立的irp没有nocache标志。这意味着加密过程中真正的磁盘读早已发生，而磁盘写被推迟。所以
FileCtxPtr->DecryptOnRead = FALSE;//明文读
FileCtxPtr->EncryptOnWrite = TRUE;//密文写
这两句就没有意义，因为等cache向disk刷新数据时，读写标志已被另外设置。
幸好，预读以FileCtxPtr->DecryptOnRead = FALSE开始，延迟写以FileCtxPtr->EncryptOnWrite = TRUE结束，因此结果无错，可是如果修改SfSetFileEncrypted等函数试图把文件加密标志写到文件中，就会出现加密标志被cache的问题

不知道上面分析的对不？

DecryptOnRead和EncryptOnWrite 标志的维护实在是件头疼的事情！

楼上大牛，我刚开始学，本打算加文件头标志，发现太复杂了，现在打算creat是判断并去尾，cleanup加尾，不用处理读写指针，这样是不是容易点？给点建议

这样处理从理论上讲的确要简单一些，但是未知的问题也很多！

引用第3楼devia于2007-04-23 18:30发表的“Re:tooflat的加密代码中SfIssueReadWriteIrpSynchronou”:
这样处理从理论上讲的确要简单一些，但是未知的问题也很多！

可是看osr上的人都喜欢加文件头，为啥呢？