lets take an example:
a. lets call the volume driver as vd and the fs encrytor as fe.
b. lets say fe creates container files like encrypted>
1. vd crates a file foo.txt with zwCrFile call, this goes thru fe, fe (by
design) encrypts the contents, and creates a file by the name foo.txt.blob
on the disk. so there is actually no foot.txt at all. it then returns th
handle of foo.txt.blob to vd, and vd assumes that it has created the right
file.
2. vd uses mark handle to lock the file (using the same handle passed by
fe), so what gets locked it foo.txt.blob.
3. vd queries for retrival pointers from FS, which goes through fe and fe
returns the retrieval pointers of foo.txt.blob
4. now vd assumes it has reserved legitmate space on the disc, and starts
doing sector based IOs on the extents of the file foo.txt, these IOs don’t
go through the FS. Since vd doesnt know that the format of the file foo was
changed to something else (see point b above), it over writes the container
header.
5. Any subsequent FS calls to this file foo.txt through the filter fe will
start to fail becasue fe won’t find tthe container the way it made it, and
assume that there is *no file called foo.txt at all (since its logic is to
translate file names from foo.txt to foo.txt.blob and see if there is a
header, if there is, remove header and give back data, but if no header, it
simply assumes that foo.txt didnt exist, and foo.txt.blob is a new file with
a diff name).
So in short hell breakes lose 
On Thu, Mar 3, 2011 at 2:49 AM, Scott Noone wrote:
> this is assumig that the volume driver stoes it’s meta data in FS
>> allocated legitimate files and not on free sectors or bad blocks
>>
>
> Sorry if I’m missing something, but isn’t this the same as any other file
> on the volume then?
>
> And say for example that I am going to do direct disk I/O to a file beneath
> the file system (which might be legitimate for some volume/disk level
> filters), then it’s my responsibility to make sure that no one moves or
> removes that file on me. Typically this is done by opening the file for
> restrictive sharing and sending an FSCTL_MARK_HANDLE request (to prevent
> defragmenting). If you’re suggesting that what you’re going to do is going
> to break those semantics then I’d agree that there’s a problem.
>
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> “A P” wrote in message news:xxxxx@ntdev…
>
> Scott,
>
> sorry, english isn’t my first language. I think I will rephrase the qn…
>
> volume level CBT drivers avoid using the FS, when it comes to storing their
> meta data. They tend to dodirect IO on the disc. This is because most of
> them need to track boot time IO also (like NTFS recovering etc) and hence
> the FS is not really up at that time, making them rely on direct IO.
>
> FS encryption softwares can cause interop here. Say this encryptor product
> embeds the file (a.txt) in an encrypted container like say a.txt.blob and
> write it to the disc. (I atleast know one one commercial FS encryptor that
> does this), so if the meta data file is renamed etc the volume level driver
> might no be able to aceess it, or even corrupt theFS encryptr data. (this is
> assumig that the volume driver stoes it’s meta data in FS allocated
> legitimate files and not on free sectors or bad blocks)
>
> This is just a design, I am open to suggestions to improve the volume meta
> data storage to avoid interop. As I said, I dont want this product to be a
> PITA for any one.
>
> AP
> On Wed, Mar 2, 2011 at 8:55 PM, Scott Noone wrote:
> “A P” wrote in message news:xxxxx@ntdev…
>
> 1. I have heard a lot of inter-op issues of volume level change tracking
> filters with file system level encryptors, mostly because these >drivers
> tend to violate the IO path and maintain their context meta data bypassing
> the file systems.
>
> I’m not sure I understand this, could you clarify? A file system filter
> that tried to circumvent the file system would be pretty nasty (and the
> encryption filters that I have been involved with certainly don’t work this
> way).
>
> Just want to make sure you’re not complicating things for yourself
> unnecessarily.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate and Chief System Problem Analyst
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>