引用第16楼dreamsity于2008-09-03 18:01发表的  :
1.操作
如果出现下面的访问序列：
(1)进程A打开fileShare，创建文件影射MapA,在文件影射上创建ViewA
(2)进程B打开fileShare，创建文件影射MapB,在文件影射上创建ViewB
(3)进程A使用memcpy修改ViewA
.......

两个FCB(Real FCB和Fake FCB)指向两个不同的SectionObject。并且这两个SectionObject不需要同步，在非Layered FSD的实现方式中，由于
Cache MGR在管理缓存（读数据/写数据）的时候，会把请求发送到同一个文件系统(NTFS/FAT)，所以这两个SectionObject
必须同步。而在Layered FSD地实现方式中，两个FCB(SectionObject)一个由真实的文件系统管理，一个由LFSD管理，所以他们的
内容不需要相同，实际上，由真实的文件系统管理的FCB(SectionObject)始终保持密文，而由LFSD管理的，则始终保持明文。

Real FCB相关的缓存操作会发送给真实的文件系统，并直接操作存储栈（读写），而Fake FCB相关的缓存操作会发送给LFSD，此时LFSD会把该
缓存中的数据加密后再发送给真实的文件系统（并不是直接把缓存中的数据加密，总之确保Fake FCB对应明文，Real FCB对应密文），通过真实的文件系统来更新到存储设备上。

之所以叫Layered FSD，就是因为该FSD并不直接操作存储栈，总是通过Real FSD来操作。

举个例子，加密文件1.txt。

密文app操作的流程：
CreateFile(1.txt) -> ReadFile(1.txt) ->WriteFile(1.txt) -> CloseFile(1.txt)

对应明文app操作的流程：
CreateFile(1.txt ' ) --> ReadFile(1.txt ' ) -> WriteFile(1.txt ' ) -> CloseFile (1.txt ' )
其中1.txt ' 是LFSD构造出来的文件(FCB)，在真实的磁盘上并不存在。

当读写1.txt ' 的时候，LFSD内部实际上是读写1.txt的内容（当然要经过加解密的处理），LFSD读写1.txt的过程，就相当于真实的FSD读写存储设备的过程。

可能我没有表达清楚，
在我举的例子中，如果进程A对视图VIEWA写入了内容AAA，
那么如果进程B直接去读VIEWB，则应该读出内容AAA。
由于写动作和读动作都是发生在内存操作里的，
这时候文件系统和CACHE管理器都是不参与这个操作的。
文件系统没有任何机会拦截到这种数据内容改变通知的。
当然，当数据被延迟写模块刷新到硬盘上的时候，我们是有机会拦截到非CACHE IO的。
我的同步的意思就是ViewA与ViewB的内容同步。
我不是很清楚这个同步该怎么完成。
如果这个同步无法处理，那么就会出现数据不一致的情况，导致文件损毁。
这个问题很容易测出来的，
编写两个内存映射的程序，同时操作一个文件。
一个是密文访问，做数据写入。
一个是明文访问，做数据读出。
比较写入内容和读出内容是否一致就知道了。

>>而Fake FCB相关的缓存操作会发送给LFSD，此时LFSD会把该
>>缓存中的数据加密后再发送给真实的文件系统
LayeredFSD本来就是FSD，缓存的读写应该是自己处理，非缓存的读写才去操作物理的文件（透过真实的FSD）。

当对内存映射的视图做操作的时候，如果数据很小（小于4K），视图内的数据被修改后，文件系统不会立即收到IRP，必须等待脏页刷新周期到了（几分钟后），这个数据才会被刷新到磁盘上的。如果在刷新前，有人把数据读走了？？？？？？？？

对了，
在NT的源代码中有cntfs模块，
这是nt4的ntfs驱动，
这个驱动已经开始支持压缩文件了。
在这里驱动内可以看到类似的双FCB的技术。
对于像我们这样拿不到layerFSD代码的，可能具备一定的参考价值。

Synchronization is a big issue for multi-FCBs because they reflect the same set of on-disk data.

引用第23楼dreamsity于2008-09-03 23:18发表的  :
当对内存映射的视图做操作的时候，如果数据很小（小于4K），视图内的数据被修改后，文件系统不会立即收到IRP，必须等待脏页刷新周期到了（几分钟后），这个数据才会被刷新到磁盘上的。如果在刷新前，有人把数据读走了？？？？？？？？

Dirty page may not be an issue. But for non-dirty pages in two caches, they must reflect the same set of on-disk data, though maybe in different format, encrypted or plain text. So I agree with you, synchronization is an issue for dual caches.

引用第22楼bluacat于2008-09-03 22:31发表的  :
>>而Fake FCB相关的缓存操作会发送给LFSD，此时LFSD会把该
>>缓存中的数据加密后再发送给真实的文件系统
LayeredFSD本来就是FSD，缓存的读写应该是自己处理，非缓存的读写才去操作物理的文件（透过真实的FSD）。

我指的是把缓存中的数据更新到存储设备，和从存储设备上读取数据到缓存。

引用第21楼dreamsity于2008-09-03 22:06发表的  :
可能我没有表达清楚，
在我举的例子中，如果进程A对视图VIEWA写入了内容AAA，
那么如果进程B直接去读VIEWB，则应该读出内容AAA。
由于写动作和读动作都是发生在内存操作里的，
这时候文件系统和CACHE管理器都是不参与这个操作的。
.......

这个和加不加密没关系，在什么都没装的系统里面一样存在这样的问题。

看样子还是在讨论，还没有人开始尝试，那我就放心了。 呵呵

dmk几年前就出来了。
而且不少的案例证明LayeredFSD也不是神药，别指望它能够解决所有的问题。

dmk也是老外的！不是国人的！要做就做中国人自己的东西。

最近发现了一个明密互斥与NTFS冲突的BUG，不管现在采用什么方案，都感觉无法彻底解决问题。
直接结果就是，要么选择蓝屏，要么选择数据损坏，两个必须选择一个。
看了几个对手公司的实现，里面也存在这个问题。
太叫我崩溃了，什么时候可以不用做明密互斥呐！
我只需要一丝曙光。。。。。。。。

AlexSho的理解应该是正确的。
其实就相当于2个文件系统，只是layeredFS对于应用来说是文件系统，对于底层文件系统来说是应用，layredFS自己内部拥有下层文件系统的一个fileobject，对上层提供一个fake fileobject。当然fake fileobject的fcb由layeredFS自己维护，为明文。

引用第32楼dreamsity于2008-09-04 16:57发表的    :
最近发现了一个明密互斥与NTFS冲突的BUG，不管现在采用什么方案，都感觉无法彻底解决问题。
直接结果就是，要么选择蓝屏，要么选择数据损坏，两个必须选择一个。
看了几个对手公司的实现，里面也存在这个问题。
太叫我崩溃了，什么时候可以不用做明密互斥呐！
我只需要一丝曙光。。。。。。。。

引用第33楼ghost2002910于2008-09-04 17:01发表的  :
AlexSho的理解应该是正确的。
其实就相当于2个文件系统，只是layeredFS对于应用来说是文件系统，对于底层文件系统来说是应用，layredFS自己内部拥有下层文件系统的一个fileobject，对上层提供一个fake fileobject。当然fake fileobject的fcb由layeredFS自己维护，为明文。

这样除非不允许那个对应密文的FCB直接写操作,否则数据就不一致了!

因为看上文我理解fake FCB和real FCB只是在某种算法下的一个一一对应的关系.并且fake FCB对应数据的变化会引起real FCB对应数据的相应变化,所以它们在那对应关系下还是一致的.
但反过来,如果real FCB对应数据的变化不会通知fake FCB把对应数据做相应变化的话,那这种一一对应就被破坏,数据就不一致了!

不知道各老大能把这种情况说明一点吗!!

引用第35楼ldljlzw于2008-09-05 14:31发表的 这样Re:第四代文件加密驱动技术讨论 filter +layerFSD ,源于OSR :


这样除非不允许那个对应密文的FCB直接写操作,否则数据就不一致了!

因为看上文我理解fake FCB和real FCB只是在某种算法下的一个一一对应的关系.并且fake FCB对应数据的变化会引起real FCB对应数据的相应变化,所以它们在那对应关系下还是一致的.
.......

   即使你能通知fake fcb去保持一致，又有什么意义呢？非可信的进程难道会按照你的格式，你的加密算法写进real fcb吗？肯定不能啊！所以即使fake能得到通知，这个时候数据已经被破坏了？

我想"非可信的进程"是一定不许写的!
不过有这个东西存在说明一定有人解决了这些问题,如果谁能搞一个BIN就一切OK了!!

耐心的等1-2个月吧！我的驱动的双fcb 的功能已经实现好了！调试通过了！现在先忙着写配置程序，和添加以下错误处理的，和一些允许子进程当作可信的进程的逻辑。

引用第36楼qianjunhua于2008-09-05 18:17发表的 Re:这样Re:第四代文件加密驱动技术讨论 filter +layerFSD ,源于OSR :

   即使你能通知fake fcb去保持一致，又有什么意义呢？非可信的进程难道会按照你的格式，你的加密算法写进real fcb吗？肯定不能啊！所以即使fake能得到通知，这个时候数据已经被破坏了？

你同时打开2个文件，难道不同步。由于layerdFS对于下层fsd本来就是一个应用，那这个realFCB只有1个，没有2个realFCB啊。