一直以来，基于进程的透明加密技术是国内文件加密市场运用最为广泛、而且也最能 为用户认可的技术。该类技术有一个最基础的问题，即加解密需要区分不同的进程，一般称为加密进程和非加密进程 或者是授权进程和非授权进程（下面我们统一简称为  授权进程和非授权进程）。
 
基本的需求是：授权进程操作的文件需要加解密：如word进程操作 doc文件 就需要加解密，而非授权进程 比如 explorer.exe 在拷贝文件的时候 就不需要加解密。这样在普通的文件拷贝和黏贴操作中 加密的文件就始终保持密文状态，从而防止文件的泄密。
 
但是Windows操作系统的设计中，为了提高效率，对文件的读写使用了缓存。这样一个加密文件如 a.doc 在被 授权进程 如 word.exe 打开过一次后 文件的内容就已经解密后被缓存到了操作的缓存管理器（CM）。此后任何进程对该文件的读写都首先检查缓存是否有该文件的内容。如果应用程序使用 FileMaping（一种对文件读写抽象技术）来读取文件的话，甚至不会发出任何的IRP请求包，这样基于文件过滤器的透明加密产品根本没有机会去处 理。
 
这样就不能满足刚才我们所说的基本要求，在osr的ntfsd新闻组 你会经常看到国内的程序员在咨询这样的技术问题。在单纯的文件过滤驱动中 最迅速的解决方式就是 不断的刷新文件的缓存，使得任何进程对加密文件的访问都发出 非缓存方式的IRP读写，然后根据进程的不同，授权进程的读写就加解密，而非授权进程的读写不加解密。
貌似这样的方案是能够很快的解决问题，但直到有一天 我看到有个英国的老外回复了一句很有深意的话，大意是这样：“用2分钟的时间 完成了这个需求 但是你得用10年的时间来解决由此带来的问题”。
 
此后在基于MiniFiler的SEFS2..0系列的项目实施过程中发现，尽管你通宵达旦的熬夜去解决某个问题，而且似 乎问题也得到了解决。但其实另一个问题同时又产生了。
 
由此我们开始反思技术路线，尽管此时 osr 的 dmk  已经发布了 3 年之久。但在这以前我们一直认为 dmk 的存在只是为了展示技术的先进性，而不能想到 dmk 为什么要做LayeredFSD。
 
 
待续。。。。。