>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