Okay, following the example of the control device object from the
minifilter samples, I’ve created my own cdo to perform some kernel-mode
functionality. In it, I find that I now need to query a file and find
out if it has one of my reparse points on it. IoCreateFile and its
brethren don’t return STATUS_REPARSE, so I can’t find out that way. I
think this leaves me with making the inquiry directly.
A couple of questions then:
Do I need to do this via minifilter calls or via legacy filter calls?
The cdo is created by my minifilter, but it’s more legacy-ish on the
inside, since it gets actual IRPs, etc.
As near as I can tell, neither Fltxxx nor Ioxxx provides a way to get
the RP data (I can set or delete with FltTag/Untag, but not query), so
I’m stuck using FSCTL_GET_REPARSE_POINT, right?
This means allocating a callback_data and doing an
FltPerformSynchronousIo, or rolling an IRP. If either of these is
usable, is one preferable to the other?
Is it kosher/halal (your choice) to call Fltxxx functions from the cdo
(I sure hope so, I’m using them to get a stream context that the
minifilter component sets. The instance pointer gets passed from the
minifilter to the user-mode service, and then into the cdo through the
ioctl interface. This does “work” by the way, at least as far as I’ve
tested. I’m more curious if it’s advisable or whether it needs to be
re-written to not use contexts some day. For what it’s worth, I
switched from using my own hash tables to using contexts without
thinking about whether or not this would be a problem. I’m hoping I
won’t have to switch back…)
Thanks,
~Eric
Try FltFsControlFile.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Eric Diven” wrote in message news:xxxxx@ntfsd…
Okay, following the example of the control device object from the
minifilter samples, I’ve created my own cdo to perform some kernel-mode
functionality. In it, I find that I now need to query a file and find
out if it has one of my reparse points on it. IoCreateFile and its
brethren don’t return STATUS_REPARSE, so I can’t find out that way. I
think this leaves me with making the inquiry directly.
A couple of questions then:
Do I need to do this via minifilter calls or via legacy filter calls?
The cdo is created by my minifilter, but it’s more legacy-ish on the
inside, since it gets actual IRPs, etc.
As near as I can tell, neither Fltxxx nor Ioxxx provides a way to get
the RP data (I can set or delete with FltTag/Untag, but not query), so
I’m stuck using FSCTL_GET_REPARSE_POINT, right?
This means allocating a callback_data and doing an
FltPerformSynchronousIo, or rolling an IRP. If either of these is
usable, is one preferable to the other?
Is it kosher/halal (your choice) to call Fltxxx functions from the cdo
(I sure hope so, I’m using them to get a stream context that the
minifilter component sets. The instance pointer gets passed from the
minifilter to the user-mode service, and then into the cdo through the
ioctl interface. This does “work” by the way, at least as far as I’ve
tested. I’m more curious if it’s advisable or whether it needs to be
re-written to not use contexts some day. For what it’s worth, I
switched from using my own hash tables to using contexts without
thinking about whether or not this would be a problem. I’m hoping I
won’t have to switch back…)
Thanks,
~Eric
Thank you, I’ll try that. It sure would be nice if the docs for
FltPerformSynchronousIo listed that as one of the preferred
alternatives.
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, February 20, 2008 1:26 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Querying reparse point data in a control device
object
Try FltFsControlFile.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Okay, following the example of the control device object from the
minifilter samples, I’ve created my own cdo to perform some kernel-mode
functionality. In it, I find that I now need to query a file and find
out if it has one of my reparse points on it. IoCreateFile and its
brethren don’t return STATUS_REPARSE, so I can’t find out that way. I
think this leaves me with making the inquiry directly.
A couple of questions then:
Do I need to do this via minifilter calls or via legacy filter calls?
The cdo is created by my minifilter, but it’s more legacy-ish on the
inside, since it gets actual IRPs, etc.
As near as I can tell, neither Fltxxx nor Ioxxx provides a way to get
the RP data (I can set or delete with FltTag/Untag, but not query), so
I’m stuck using FSCTL_GET_REPARSE_POINT, right?
This means allocating a callback_data and doing an
FltPerformSynchronousIo, or rolling an IRP. If either of these is
usable, is one preferable to the other?
Is it kosher/halal (your choice) to call Fltxxx functions from the cdo
(I sure hope so, I’m using them to get a stream context that the
minifilter component sets. The instance pointer gets passed from the
minifilter to the user-mode service, and then into the cdo through the
ioctl interface. This does “work” by the way, at least as far as I’ve
tested. I’m more curious if it’s advisable or whether it needs to be
re-written to not use contexts some day. For what it’s worth, I
switched from using my own hash tables to using contexts without
thinking about whether or not this would be a problem. I’m hoping I
won’t have to switch back…)
Thanks,
~Eric
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@edsiohio.com
To unsubscribe send a blank email to xxxxx@lists.osr.com