Hello,
Actually, rolling your own create irp isn’t so bad. If you do a
search on OSR’s website, you can find an old post from Mr. Hrdina Pavel that
has some functional code that does just this. I’ve used it, and it seems to
work. The only difficult (undocumented) part is setting up the security
context.
Are you issuing the ‘create’ from within your create dispatch
routine? If so, a better solution might be to ‘hijack’ the original create
irp, alter it to suit your needs, issue it to the FSD, issue a cleanup and
close, restore the irp to its original state and send it again. This works
well, and is probably safer in the long run than calling undocumented
routines to roll your own create irp.
I expect you could also put some name you expect to be unique after
the name of the volume you are filtering. I haven’t tried this, but it
seems like it should work: For example, to open
\Device\HarddiskVolume1\Whatever.txt, you would call ZwCreateFile with
\Device\HarddiskVolume1**UNIQUE STRING HERE**\Whatever.txt. When you got a
request for
**UNIQUE STRING HERE**\Whatever.txt, you’ll know you generated it, and you
can avoid doing whatever your trying to avoid before stripping the header
and sending it down. Again, I haven’t tried this, but it seems like it
should work. Of course, there is the risk that the volume you are filtering
actually HAS a **UNIQUE STRING HERE**\ directory, at which point…
If you need any code for the first two techniques, reply to the list
and I’ll send it up (In exchange for others critiquing it and pointing out
its flaws!)
-Joel
-----Original Message-----
From: xxxxx@earthlink.net [mailto:xxxxx@earthlink.net]
Sent: Wednesday, February 14, 2001 10:00 AM
To: File Systems Developers
Subject: [ntfsd] Question on preventing my driver from filtering it’s
own transactions…
Howdy!
I have been working to resolve this problem without much success. The
issue is as follows:
* My filter driver filters out IRP_MJ_CREATEs to perform work relative to
specific types of creates
* In the course of events, I need to create a folder on a volume, so I use
IoCreateFile(…) and the directory gets created.
The problem is that the IoCreateFile(…) generates an IRP_MJ_CREATE irp
that my driver is then going to filter.
I tried to prevent the driver from filtering any IRP that had
tail.overlay.thread == PsGetCurrentThread(), but this doesn’t work
properly. This is because when my driver is operating in the same thread
as an IRP issued from user-land, it can potentially ignore these IRPs as
well as the ones I create.
How do I go about “tagging” an IRP with information showing that it has
been generated by my own driver (and thus I should ignore it)? In other
transactions I would roll my own IRP, but in previous e-mails on another
issue it was recommended that I do not attempt to roll a create irp as
these are quite complex. So, as you can see I am a bit stuck.
thanks. - jb
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com