I’d call that a bug in FE, it’s not preserving the file system’s semantics
here. If I open a file up and plow through its contents I don’t expect to
not be able to find the file afterwards (though I would expect the contents
to not be encrypted, which may or not be a concern depending on the design).
-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…
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