Re: IRP Create

Comments inline:
"Beat Muller" <chom_62@xxxxxxxxxxx> wrote in message
news:eYOTzuoHHHA.4112@xxxxxxxxxxxxxxxxxxxxxxx
Subject: Activity Info in IRP_CREATEs

Thank you very much for your fast and highly professional answers, Anton
and Don!

Your replies showed me 2 things: It looks like I still gotta learn a lot
more about the file system and it also showed me that my file system
driver code isn't as bad as I thought it could be.

A specific reply to you, Anton:

How is IO Manager supposed to know which particular function the client
code is about to call next while it processes ZwCreateFile() call???:

Having worked in OS kernels for 35 years, I have never seen this
capability.

It looks like that not all the information the Win32 Subsystem knows is
shared with the IO Manager. I'm sure if the driver model could be
redesigned from scratch without regard to any compatibilty issues one of
these levels would be omitted. That's what I would do, anyway. Then the
IRP_CREATE op would indeed include the type of file operation that is
going to be carried out, so it could be manipulated (eg blocked) at that
early stage if the need arised. Are you listening, Microsoft FS driver
programmers? Here is what (some of) your customers want!

And how would you handle the case of adding an operation? Does an
extension to a current call require a multi-year slip in all work since
every component that uses IRP's and opens would now have to address this
potential new call (I ask this since I know of a professor who wanted this
in his OS, of course the project never was completed). Every OS that I
have ever seen uses a generic model of permissions on an open and then
required permissions for a specific call, trying to map everything is only
making things way to complex.
Note: the Win32 and subsystem does not know more than it passes.

Now to your remark, Don:

"Tracking file names is hard, the examples in WDK/IFS kit show a large
amount of effort in handling these cases."

You are dead right! It was very hard indeed to track the filenames. But
after having removed a bug in the IFS Kit (CD version) things looked much
better. That bug never manifested itself in the filter sample provided
but it raised its ugly head when the FileName routines were taken from
the logging environment. It's kind of a mistake that hardly ever occurs
when professional programmers write code, rather, I have the sneaky
suspicion that this bug was implemented on purpose...

You are being paranoid, bugs happen they are not put in on purpose. You
should not need this stuff if you use a mini-filter, and bottom line is
unless there is really a compelling reason to not to you should use a
mini-filter. Which version of the CD are you using? You should now be
using the WDK since there are bug fixes in this code (I know I submitted
some of the bug reports)


I also thougt that the IFS kit provides just the bare minimum of aid and
it is still very hard to get started. Microsoft could have done a much
better job to make this start easier, or was that also done on purpose???


Be thankful for what you get. Those samples and other portions of the IFS
kit were a lot of man-years. Microsoft is not making money on this. For
years the only way to get information was to have gone to the one early
Microsoft conference on file systems (where they thought they would have 20
people and cut it off well above that), know someone who had gone to that
conference, or take a class from OSR for a lot of money and type in the
headers from the OSR slides yourself.

Like everything else, the IFS kit slowly is improving, and the mini-filter
model is a joy to work in versus the old stuff. The samples and
documentation keep growing and improving, especially since this is a tiny
community that does file system work. For now I would recomend you ask
your questions on NTFSD at http://www.osronline.com since that is the list
for file systems (the Microsoft people who bring you the IFS kit hang out
there not here).


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



.