I’m writing a minifilter that needs to process the writes on a volume.
To attach to the volume I use the FltAttachVolume() function and I have a
PreWriteCallback routine in which I process the FLT_CALLBACK_DATA.
The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get the
offset relative to the start of the file or data that is written and not to
the volume itself ( for example if data is written in the file 1.txt, the
Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following
write would start from offset 8192…and so on).
Inspecting the Device Tree this behaviour makes sense because I see that the
FltMgr is attached on top of NTFS that is attached on top of
\Device\HarddiskVolumeXXX .
Is there possible to obtain somehow the offset relative to the volume itself
in the PreWriteCallback routine ? ( I thought that by using the
FltAttachVolume the filter attaches directly on top of the volume…not on
top of the fs )
You either need a disk filter which will attach to the volume, but which you
will not see individual file writes just the blocks. Or you need to
monitor the writes and translate them yourself into volume data (this latter
is doable but ugly).
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com
Remove StopSpam from the email to reply
“Victor Asavei” wrote in message news:xxxxx@ntfsd… Hi all
I’m writing a minifilter that needs to process the writes on a volume. To attach to the volume I use the FltAttachVolume() function and I have a PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get the offset relative to the start of the file or data that is written and not to the volume itself ( for example if data is written in the file 1.txt, the Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following write would start from offset 8192…and so on). Inspecting the Device Tree this behaviour makes sense because I see that the FltMgr is attached on top of NTFS that is attached on top of \Device\HarddiskVolumeXXX .
Is there possible to obtain somehow the offset relative to the volume itself in the PreWriteCallback routine ? ( I thought that by using the FltAttachVolume the filter attaches directly on top of the volume…not on top of the fs )
Well…I don’t need to see the files at all…I exactly need just the blocks
but relative to the volume…not to the files.
So…as I understand the solution is to drop the minifilter and to write a
disk filter and use the IoAttachDevice() routine ?
On 5/19/06, Don Burn wrote: > > You either need a disk filter which will attach to the volume, but which > you > will not see individual file writes just the blocks. Or you need to > monitor the writes and translate them yourself into volume data (this > latter > is doable but ugly). > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > http://www.windrvr.com > Remove StopSpam from the email to reply > > > > “Victor Asavei” wrote in message > news:xxxxx@ntfsd… > Hi all > > I’m writing a minifilter that needs to process the writes on a volume. > To attach to the volume I use the FltAttachVolume() function and I have a > PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. > The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get > the > offset relative to the start of the file or data that is written and not > to > the volume itself ( for example if data is written in the file 1.txt, the > Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following > write would start from offset 8192…and so on). > Inspecting the Device Tree this behaviour makes sense because I see that > the > FltMgr is attached on top of NTFS that is attached on top of > \Device\HarddiskVolumeXXX . > > Is there possible to obtain somehow the offset relative to the volume > itself > in the PreWriteCallback routine ? ( I thought that by using the > FltAttachVolume the filter attaches directly on top of the volume…not on > top of the fs ) > > > Victor > > > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
Dan.
----- Original Message -----
From: Victor Asavei
To: Windows File Systems Devs Interest List
Sent: Friday, May 19, 2006 10:16 AM
Subject: Re: [ntfsd] FltAttachVolume
Well…I don’t need to see the files at all…I exactly need just the blocks but relative to the volume…not to the files.
So…as I understand the solution is to drop the minifilter and to write a disk filter and use the IoAttachDevice() routine ?
On 5/19/06, Don Burn wrote: You either need a disk filter which will attach to the volume, but which you will not see individual file writes just the blocks. Or you need to monitor the writes and translate them yourself into volume data (this latter is doable but ugly).
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com Remove StopSpam from the email to reply
“Victor Asavei” wrote in message news:xxxxx@ntfsd… Hi all
I’m writing a minifilter that needs to process the writes on a volume. To attach to the volume I use the FltAttachVolume() function and I have a PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get the offset relative to the start of the file or data that is written and not to the volume itself ( for example if data is written in the file 1.txt, the Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following write would start from offset 8192…and so on). Inspecting the Device Tree this behaviour makes sense because I see that the FltMgr is attached on top of NTFS that is attached on top of \Device\HarddiskVolumeXXX .
Is there possible to obtain somehow the offset relative to the volume itself in the PreWriteCallback routine ? ( I thought that by using the FltAttachVolume the filter attaches directly on top of the volume…not on top of the fs )
Actually, I would start with KMDF these days not DiskPerf. I have done
several filters based on DiskPerf, but recently I tried my first KMDF driver
as a disk filter, even with the KMDF learning curve the time was the same as
taking one of the drivers I have worked with before. It was a lot less
code, and easier to modify. I will not go back.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com
Remove StopSpam from the email to reply
“Dan Kyler” wrote in message news:xxxxx@ntfsd… Yes. See the diskperf example.
- Dan. ----- Original Message ----- From: Victor Asavei To: Windows File Systems Devs Interest List Sent: Friday, May 19, 2006 10:16 AM Subject: Re: [ntfsd] FltAttachVolume
Well…I don’t need to see the files at all…I exactly need just the blocks but relative to the volume…not to the files. So…as I understand the solution is to drop the minifilter and to write a disk filter and use the IoAttachDevice() routine ?
On 5/19/06, Don Burn wrote: You either need a disk filter which will attach to the volume, but which you will not see individual file writes just the blocks. Or you need to monitor the writes and translate them yourself into volume data (this latter is doable but ugly).
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com Remove StopSpam from the email to reply
“Victor Asavei” wrote in message news:xxxxx@ntfsd… Hi all
I’m writing a minifilter that needs to process the writes on a volume. To attach to the volume I use the FltAttachVolume() function and I have a PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get the offset relative to the start of the file or data that is written and not to the volume itself ( for example if data is written in the file 1.txt, the Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following write would start from offset 8192…and so on). Inspecting the Device Tree this behaviour makes sense because I see that the FltMgr is attached on top of NTFS that is attached on top of \Device\HarddiskVolumeXXX .
Is there possible to obtain somehow the offset relative to the volume itself in the PreWriteCallback routine ? ( I thought that by using the FltAttachVolume the filter attaches directly on top of the volume…not on top of the fs )
However, I would add that the OP should read the relevant NT Insider
article, and the relevant archives of NTDEV, to figure out how to install
the damn thing.
Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, May 19, 2006 10:46 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FltAttachVolume
Actually, I would start with KMDF these days not DiskPerf. I have done
several filters based on DiskPerf, but recently I tried my first KMDF driver
as a disk filter, even with the KMDF learning curve the time was the same as
taking one of the drivers I have worked with before. It was a lot less
code, and easier to modify. I will not go back.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com
Remove StopSpam from the email to reply
“Dan Kyler” wrote in message news:xxxxx@ntfsd… Yes. See the diskperf example.
- Dan. ----- Original Message ----- From: Victor Asavei To: Windows File Systems Devs Interest List Sent: Friday, May 19, 2006 10:16 AM Subject: Re: [ntfsd] FltAttachVolume
Well…I don’t need to see the files at all…I exactly need just the blocks but relative to the volume…not to the files. So…as I understand the solution is to drop the minifilter and to write a
disk filter and use the IoAttachDevice() routine ?
On 5/19/06, Don Burn wrote: You either need a disk filter which will attach to the volume, but which
you will not see individual file writes just the blocks. Or you need to monitor the writes and translate them yourself into volume data (this latter is doable but ugly).
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com Remove StopSpam from the email to reply
“Victor Asavei” wrote in message news:xxxxx@ntfsd… Hi all
I’m writing a minifilter that needs to process the writes on a volume. To attach to the volume I use the FltAttachVolume() function and I have a PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get
the offset relative to the start of the file or data that is written and not
to the volume itself ( for example if data is written in the file 1.txt, the Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following write would start from offset 8192…and so on). Inspecting the Device Tree this behaviour makes sense because I see that
the FltMgr is attached on top of NTFS that is attached on top of \Device\HarddiskVolumeXXX .
Is there possible to obtain somehow the offset relative to the volume itself in the PreWriteCallback routine ? ( I thought that by using the FltAttachVolume the filter attaches directly on top of the volume…not on top of the fs )
— Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
I started writing a disk filter but it seems that I’ve run into some
problems.
I successfully attach to the volume (e.g. \Device\HarddiskVolume1\ ) but it
seems that I don’t recieve the IRP’s for the volume that first I need to
process (IRP_MJ_READ and IRP_MJ_WRITE). I’ve tried also to attach directly
to the disk (e.g. \Device\Harddisk0\DR0 ) but with the same results.
Looking with device tree the device stack is \Device\HarddiskVolume1\ —
Volsnap — MyDriver and when attaching directly to the disk
\Device\Harddisk0\DR0 — PartMgr – MyDriver
Any idea why I don’t get the IRP’s ?
On 5/19/06, Don Burn wrote: > > You either need a disk filter which will attach to the volume, but which > you > will not see individual file writes just the blocks. Or you need to > monitor the writes and translate them yourself into volume data (this > latter > is doable but ugly). > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > http://www.windrvr.com > Remove StopSpam from the email to reply > > > > “Victor Asavei” wrote in message > news:xxxxx@ntfsd… > Hi all > > I’m writing a minifilter that needs to process the writes on a volume. > To attach to the volume I use the FltAttachVolume() function and I have a > PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. > The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get > the > offset relative to the start of the file or data that is written and not > to > the volume itself ( for example if data is written in the file 1.txt, the > Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following > write would start from offset 8192…and so on). > Inspecting the Device Tree this behaviour makes sense because I see that > the > FltMgr is attached on top of NTFS that is attached on top of > \Device\HarddiskVolumeXXX . > > Is there possible to obtain somehow the offset relative to the volume > itself > in the PreWriteCallback routine ? ( I thought that by using the > FltAttachVolume the filter attaches directly on top of the volume…not on > top of the fs ) > > > Victor > > > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
You’re loading and attaching too late. The file system already has the volume mounted, and has a pointer to the driver beneath you.
Your driver should be boot start, group “PNP Filter”, listed as an upper filter for the volume or disk class, and you should attach in AddDevice.
Dan.
----- Original Message -----
From: Victor Asavei
To: Windows File Systems Devs Interest List
Sent: Monday, May 22, 2006 5:05 AM
Subject: Re: [ntfsd] FltAttachVolume
I started writing a disk filter but it seems that I’ve run into some problems.
I successfully attach to the volume (e.g. \Device\HarddiskVolume1\ ) but it seems that I don’t recieve the IRP’s for the volume that first I need to process (IRP_MJ_READ and IRP_MJ_WRITE). I’ve tried also to attach directly to the disk (e.g. \Device\Harddisk0\DR0 ) but with the same results.
Looking with device tree the device stack is \Device\HarddiskVolume1\ — Volsnap — MyDriver and when attaching directly to the disk \Device\Harddisk0\DR0 — PartMgr – MyDriver
Any idea why I don’t get the IRP’s ?
On 5/19/06, Don Burn wrote: You either need a disk filter which will attach to the volume, but which you will not see individual file writes just the blocks. Or you need to monitor the writes and translate them yourself into volume data (this latter is doable but ugly).
– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting http://www.windrvr.com Remove StopSpam from the email to reply
“Victor Asavei” wrote in message news:xxxxx@ntfsd… Hi all
I’m writing a minifilter that needs to process the writes on a volume. To attach to the volume I use the FltAttachVolume() function and I have a PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get the offset relative to the start of the file or data that is written and not to the volume itself ( for example if data is written in the file 1.txt, the Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a following write would start from offset 8192…and so on). Inspecting the Device Tree this behaviour makes sense because I see that the FltMgr is attached on top of NTFS that is attached on top of \Device\HarddiskVolumeXXX .
Is there possible to obtain somehow the offset relative to the volume itself in the PreWriteCallback routine ? ( I thought that by using the FltAttachVolume the filter attaches directly on top of the volume…not on top of the fs )
Well, I have followed your sugestion and looked at the diskperf example and
I saw that it does exactly what you have said but being boot start it needs
to reboot the machine a thing that I want to avoid…so my driver is group
“PNP filter”, listed as an upper filter but doesn’t attach in AddDevice and
it is demand start.
My fault that I didn’t mention that I’m searching for a way to attach and
load that doesn’t imply a reboot of the machine (so that the driver can be
loaded at boot time). I want to load the driver, attach to the volume/disk,
do my work, deattach and unload.
Is this possible ? With the minifilter that I have already written I could
attach to the volume without rebooting (surely because FltMgr is attaching
at boot time) and I’m looking to obtain something similar with the disk
filter.
Also, Don you mentioned in a previous answer that with a minifilter you
could monitor the writes and then translate them in volume data but it is
pretty complicated ! Could you detail a little bit please ?
I really need to find a way to monitor the writes and before allowing them
to proceed to backup the data from the clusters they need to write.
On 5/22/06, Dan Kyler wrote: > > You’re loading and attaching too late. The file system already has the > volume mounted, and has a pointer to the driver beneath you. > > Your driver should be boot start, group “PNP Filter”, listed as an upper > filter for the volume or disk class, and you should attach in AddDevice. > > - Dan. > > ----- Original Message ----- > From: Victor Asavei > To: Windows File Systems Devs Interest List > Sent: Monday, May 22, 2006 5:05 AM > Subject: Re: [ntfsd] FltAttachVolume > > I started writing a disk filter but it seems that I’ve run into some > problems. > I successfully attach to the volume (e.g. \Device\HarddiskVolume1\ ) but > it seems that I don’t recieve the IRP’s for the volume that first I need to > process (IRP_MJ_READ and IRP_MJ_WRITE). I’ve tried also to attach directly > to the disk (e.g. \Device\Harddisk0\DR0 ) but with the same results. > Looking with device tree the device stack is \Device\HarddiskVolume1\ — > Volsnap — MyDriver and when attaching directly to the disk > \Device\Harddisk0\DR0 — PartMgr – MyDriver > > Any idea why I don’t get the IRP’s ? > > > On 5/19/06, Don Burn wrote: > > > > You either need a disk filter which will attach to the volume, but which > > you > > will not see individual file writes just the blocks. Or you need to > > monitor the writes and translate them yourself into volume data (this > > latter > > is doable but ugly). > > > > > > – > > Don Burn (MVP, Windows DDK) > > Windows 2k/XP/2k3 Filesystem and Driver Consulting > > http://www.windrvr.com > > Remove StopSpam from the email to reply > > > > > > > > “Victor Asavei” wrote in message > > news:xxxxx@ntfsd… > > Hi all > > > > I’m writing a minifilter that needs to process the writes on a volume. > > To attach to the volume I use the FltAttachVolume() function and I have > > a > > PreWriteCallback routine in which I process the FLT_CALLBACK_DATA. > > The problem is that in the Data->Iopb->Parameters.Write.ByteOffset I get > > the > > offset relative to the start of the file or data that is written and not > > to > > the volume itself ( for example if data is written in the file 1.txt, > > the > > Write.Length is 8192 - 2 clusters, the Write.ByteOffset is 0 ; a > > following > > write would start from offset 8192…and so on). > > Inspecting the Device Tree this behaviour makes sense because I see that > > the > > FltMgr is attached on top of NTFS that is attached on top of > > \Device\HarddiskVolumeXXX . > > > > Is there possible to obtain somehow the offset relative to the volume > > itself > > in the PreWriteCallback routine ? ( I thought that by using the > > FltAttachVolume the filter attaches directly on top of the volume…not > > on > > top of the fs ) > > > > > > Victor > > > > > > > > — > > Questions? First check the IFS FAQ at > > https://www.osronline.com/article.cfm?id=17 > > > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > — Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 You are currently subscribed > to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank > email to xxxxx@lists.osr.com > — > > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ > > To unsubscribe send a blank email to xxxxx@lists.osr.com >
>My fault that I didn’t mention that I’m searching for a way to attach and
load that doesn’t imply a reboot of the machine (so that the driver can be
loaded at boot time). I want to load the driver, attach to the volume/disk,
do my work, deattach and unload.
Well…since I can’t get this behaviour using filter drivers or minifilters
I will try another approach : I’m going to try to hook the dispatch for the
IRP_MJ_WRITE from the Driver dispatch table, more exactly replacing the
dispatch routine with my local dispatch.
In my local dispatch I will process the IRP (I’m interested only in the
data…not altering the irp or stack at all) and then I will call the real
dispatch routine of the driver I will hook.
On 5/22/06, Maxim S. Shatskih wrote: > > >My fault that I didn’t mention that I’m searching for a way to attach and > >load that doesn’t imply a reboot of the machine (so that the driver can > be > >loaded at boot time). I want to load the driver, attach to the > volume/disk, > >do my work, deattach and unload. > > You cannot do this with the SystemRoot disk. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
----- Original Message -----
From: “Victor Asavei” To: “Windows File Systems Devs Interest List” Sent: Tuesday, May 23, 2006 11:17 PM Subject: Re: [ntfsd] FltAttachVolume
Well…since I can’t get this behaviour using filter drivers or minifilters I will try another approach : I’m going to try to hook the dispatch for the IRP_MJ_WRITE from the Driver dispatch table, more exactly replacing the dispatch routine with my local dispatch. In my local dispatch I will process the IRP (I’m interested only in the data…not altering the irp or stack at all) and then I will call the real dispatch routine of the driver I will hook.
On 5/22/06, Maxim S. Shatskih wrote: > > >My fault that I didn’t mention that I’m searching for a way to attach and > >load that doesn’t imply a reboot of the machine (so that the driver can > be > >loaded at boot time). I want to load the driver, attach to the > volume/disk, > >do my work, deattach and unload. > > You cannot do this with the SystemRoot disk. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
On 5/23/06, Maxim S. Shatskih wrote: > > So what? You will miss lots of writes done before your driver’s > install. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > ----- Original Message ----- > From: “Victor Asavei” > To: “Windows File Systems Devs Interest List” > Sent: Tuesday, May 23, 2006 11:17 PM > Subject: Re: [ntfsd] FltAttachVolume > > > Well…since I can’t get this behaviour using filter drivers or > minifilters > I will try another approach : I’m going to try to hook the dispatch for > the > IRP_MJ_WRITE from the Driver dispatch table, more exactly replacing the > dispatch routine with my local dispatch. > In my local dispatch I will process the IRP (I’m interested only in the > data…not altering the irp or stack at all) and then I will call the real > dispatch routine of the driver I will hook. > > > > On 5/22/06, Maxim S. Shatskih wrote: > > > > >My fault that I didn’t mention that I’m searching for a way to attach > and > > >load that doesn’t imply a reboot of the machine (so that the driver can > > be > > >loaded at boot time). I want to load the driver, attach to the > > volume/disk, > > >do my work, deattach and unload. > > > > You cannot do this with the SystemRoot disk. > > > > Maxim Shatskih, Windows DDK MVP > > StorageCraft Corporation > > xxxxx@storagecraft.com > > http://www.storagecraft.com > > > > > > — > > Questions? First check the IFS FAQ at > > https://www.osronline.com/article.cfm?id=17 > > > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > — > Questions? First check the IFS FAQ at > https://www.osronline.com/article.cfm?id=17 > > You are currently subscribed to ntfsd as: xxxxx@gmail.com > To unsubscribe send a blank email to xxxxx@lists.osr.com >
What is the behavior that you can’t get with a volume filter? Not rebooting? Your customers WILL reboot with the approach you suggest–just not predictably.
Don’t forget to tell us the name of the product you are working on so that we can ensure it never gets on our systems.
Dan.
----- Original Message -----
From: Victor Asavei
To: Windows File Systems Devs Interest List
Sent: Tuesday, May 23, 2006 1:17 PM
Subject: Re: [ntfsd] FltAttachVolume
Well…since I can’t get this behaviour using filter drivers or minifilters I will try another approach : I’m going to try to hook the dispatch for the IRP_MJ_WRITE from the Driver dispatch table, more exactly replacing the dispatch routine with my local dispatch.
In my local dispatch I will process the IRP (I’m interested only in the data…not altering the irp or stack at all) and then I will call the real dispatch routine of the driver I will hook.
On 5/22/06, Maxim S. Shatskih wrote: >My fault that I didn’t mention that I’m searching for a way to attach and >load that doesn’t imply a reboot of the machine (so that the driver can be >loaded at boot time). I want to load the driver, attach to the volume/disk, >do my work, deattach and unload.