Hi, All.
Currently we deal with Storage drivers stack.
In some cases we don’t want the File System to
be mounted on some volumes. Is it possible to affect, somehow,
File System mounting process in Windows 2K/XP?
The problem is that we would like to act from SCSI Disk
Lower Filter Driver.
Thanks in advance.
SH.
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
If you open the device with just FILE_READ_ATTRIBUTES you can open the
device without mounting as the IO manager skips the filesystem path. Please
be aware that this obviously restricts the accesses granted to your handles.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Shaggy Head” wrote in message news:xxxxx@ntdev…
>
> Hi, All.
> Currently we deal with Storage drivers stack.
> In some cases we don’t want the File System to
> be mounted on some volumes. Is it possible to affect, somehow,
> File System mounting process in Windows 2K/XP?
> The problem is that we would like to act from SCSI Disk
> Lower Filter Driver.
> Thanks in advance.
> SH.
>
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
>
>
Nar, I believe the original requestor was asking how to prevent Windows from
mounting the media on insertion rather than how to avoid a particular call
of his from mounting the media. “Shaggy Head”, please let us know which
interpretation you mean.
In answer to my interpretation of the question, it seems there are two
options:
Have your lower level SCSI filter catch the arrival of the media and
“spoof” the data so that the rest of the system will interpret it as the
media NOT arriving. This means, of course, you will need to provide some
“back door” (IOCTLs, probably) for your own code to access the media so it
can decide when (and when not) to mount the media. Also, when you decide to
turn off the “media-not-there” condition, YOU will need to generate all the
appropriate arrival calls. This method has the advantage of being simpler
to implement, but the interactions with other folks’ drivers can be a
problem and solvable only through testing.
Build a file system (IFS) that claims the media when it arrives, and
then releases it when the user decides its okay to mount. I would argue
against this method - kind of like trying to kill a fly with a sledghammer.
Writing an IFS, even a simple one, is NOT for the faint of heart (or small
of budget). Also, making sure your IFS is always called first can be a bit
of a pain.
Neither of these approaches are simple, but I recommend the first. Most CD
writing systems use some variant of the first method to allow blank media to
be inserted but not mounted by the system.
No matter what you choose, if you are a new driver writer, PLEASE take the
time to attend a good driver writing seminar! I took OSR’s seminars a few
years back and have been very glad I did! There are others on the market,
so check around. Also, check out the examples in the DDK –
src\storage\filters\diskperf might be a good start.
Good luck!
Stu Bell
-----Original Message-----
From: Nar Ganapathy [MS] [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, July 22, 2002 10:26 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.If you open the device with just FILE_READ_ATTRIBUTES you can open the
device without mounting as the IO manager skips the
filesystem path. Please
be aware that this obviously restricts the accesses granted
to your handles.–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and
confers no rights.
“Shaggy Head” wrote in message
news:xxxxx@ntdev…
>
> Hi, All.
> Currently we deal with Storage drivers stack.
> In some cases we don’t want the File System to
> be mounted on some volumes. Is it possible to affect, somehow,
> File System mounting process in Windows 2K/XP?
> The problem is that we would like to act from SCSI Disk
> Lower Filter Driver.
> Thanks in advance.
> SH.
>
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
>
>
—
You are currently subscribed to ntdev as: xxxxx@dataplay.com
To unsubscribe send a blank email to %%email.unsub%%
Thanks for answers.
Stu, the fist way you suggested looks better. Actually we kept
in mind just this approach. And the question was how to make
the system thinking that the media not arriving.
We are able to “spoof” MBR data intercepting SRBs while
initializing. But it seems to us that this approach isn’t regular.
We are searching for another one.
If preventing Windows from mounting isn’t possible from
lower level Storage Filter Driver, may be we could just halt
driver stack building until some event occurs or IOCTL
arrives.
Is there in Windows 2K/XP model any legal possibility to
halt driver stack building for a quite long period of time?
SH.
From: Stu Bell
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: How to avoid FS mounting.
>Date: Mon, 22 Jul 2002 14:44:35 -0600
>
>Nar, I believe the original requestor was asking how to prevent Windows
>from
>mounting the media on insertion rather than how to avoid a particular call
>of his from mounting the media. “Shaggy Head”, please let us know which
>interpretation you mean.
>
>In answer to my interpretation of the question, it seems there are two
>options:
>
>1) Have your lower level SCSI filter catch the arrival of the media and
>“spoof” the data so that the rest of the system will interpret it as the
>media NOT arriving. This means, of course, you will need to provide some
>“back door” (IOCTLs, probably) for your own code to access the media so it
>can decide when (and when not) to mount the media. Also, when you decide
>to
>turn off the “media-not-there” condition, YOU will need to generate all the
>appropriate arrival calls. This method has the advantage of being simpler
>to implement, but the interactions with other folks’ drivers can be a
>problem and solvable only through testing.
>
>2) Build a file system (IFS) that claims the media when it arrives, and
>then releases it when the user decides its okay to mount. I would argue
>against this method - kind of like trying to kill a fly with a sledghammer.
>Writing an IFS, even a simple one, is NOT for the faint of heart (or small
>of budget). Also, making sure your IFS is always called first can be a bit
>of a pain.
>
>Neither of these approaches are simple, but I recommend the first. Most CD
>writing systems use some variant of the first method to allow blank media
>to
>be inserted but not mounted by the system.
>
>No matter what you choose, if you are a new driver writer, PLEASE take the
>time to attend a good driver writing seminar! I took OSR’s seminars a few
>years back and have been very glad I did! There are others on the market,
>so check around. Also, check out the examples in the DDK –
>src\storage\filters\diskperf might be a good start.
>
>Good luck!
>
>Stu Bell
>
> > -----Original Message-----
> > From: Nar Ganapathy [MS] [mailto:xxxxx@windows.microsoft.com]
> > Sent: Monday, July 22, 2002 10:26 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: How to avoid FS mounting.
> >
> >
> > If you open the device with just FILE_READ_ATTRIBUTES you can open the
> > device without mounting as the IO manager skips the
> > filesystem path. Please
> > be aware that this obviously restricts the accesses granted
> > to your handles.
> >
> > –
> > Nar Ganapathy
> > Windows Core OS group
> > This posting is provided “AS IS” with no warranties, and
> > confers no rights.
> > “Shaggy Head” wrote in message
>news:xxxxx@ntdev…
> >
> > Hi, All.
> > Currently we deal with Storage drivers stack.
> > In some cases we don’t want the File System to
> > be mounted on some volumes. Is it possible to affect, somehow,
> > File System mounting process in Windows 2K/XP?
> > The problem is that we would like to act from SCSI Disk
> > Lower Filter Driver.
> > Thanks in advance.
> > SH.
> >
> >
> >
> >
> > MSN Photos is the easiest way to share and print your photos:
> > http://photos.msn.com/support/worldwide.aspx
> >
> >
> >
> >
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@dataplay.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%
Chat with friends online, try MSN Messenger: http://messenger.msn.com
> We are able to “spoof” MBR data intercepting SRBs while
initializing. But it seems to us that this approach isn’t regular.
Yup, you’re already too late. You need to look for the media arrival event.
On CDs, this was usually an IRP_MJ_DEVICE_CONTROL with an
IOCTL_SCSI_PASS_THROUGH or IOCTL_SCSI_PASS_THROUGH_DIRECT containing a
TestUnitReady (0x00) command. When this changed from SC/ASC/ASCQ 5/3A/00 to
either 0/0/0 (no error) or 02/04/01 (Not Ready - becoming ready) or 02/28/00
(Not ready to change - medium may have arrived), THEN you need to start
switching results back to the5/3A/00, along with the appropriate error
settings. Other devices (Zip, PCMCIA disks, USB disks, …) MAY behave the
same, but you’d better assume that they don’t.
You essentially want to convince the system that there is still NO MEDIA IN
THE DRIVE. If you can do that, you can run your own little routines through
a direct IOCTL connect to your filter and, when you deem it time, have the
media “arrive” by sending the correct codes up through the stack.
Your particular device may have a different arrival protocol. I would
recommend that you have your filter spit out a debug statement on every IRP
that goes through your filter and watch what happens when the media arrives.
You’ll be able to watch the results with either a debugger (WinDbg, SoftICE)
or DebugView (see www.sysinternals.com or www.osr.com - I personally prefer
the one from SysInternals (sorry, OSR)).
My other concern is your comment about “spoofing” MBR data - are you trying
to do this mount control at boot time? If so, would you mind sharing why?
If preventing Windows from mounting isn’t possible from
lower level Storage Filter Driver, may be we could just halt
driver stack building until some event occurs or IOCTL
arrives.
PLEASE don’t try this. It will cause endless headaches not only for you,
but for anyone using your software. Besides, you can’t really do that and
have the system come up correctly. And what happens when the media arrives
after the system is up?
Is there in Windows 2K/XP model any legal possibility to
halt driver stack building for a quite long period of time?
No, there isn’t. And any “illegal” method will fail driver qualification AT
LEAST. And it would be guaranteed to piss off the rest of the driver
writing community. You don’t want that do you? Nah, I didn’t think so.
Good luck!
Stu Bell
Thanks, Stu.
It helps.
SH.
From: Stu Bell
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: How to avoid FS mounting.
>Date: Tue, 23 Jul 2002 12:27:30 -0600
>
> > We are able to “spoof” MBR data intercepting SRBs while
> > initializing. But it seems to us that this approach isn’t regular.
>
>Yup, you’re already too late. You need to look for the media arrival
>event.
>On CDs, this was usually an IRP_MJ_DEVICE_CONTROL with an
>IOCTL_SCSI_PASS_THROUGH or IOCTL_SCSI_PASS_THROUGH_DIRECT containing a
>TestUnitReady (0x00) command. When this changed from SC/ASC/ASCQ 5/3A/00
>to
>either 0/0/0 (no error) or 02/04/01 (Not Ready - becoming ready) or
>02/28/00
>(Not ready to change - medium may have arrived), THEN you need to start
>switching results back to the5/3A/00, along with the appropriate error
>settings. Other devices (Zip, PCMCIA disks, USB disks, …) MAY behave the
>same, but you’d better assume that they don’t.
>
>You essentially want to convince the system that there is still NO MEDIA IN
>THE DRIVE. If you can do that, you can run your own little routines
>through
>a direct IOCTL connect to your filter and, when you deem it time, have the
>media “arrive” by sending the correct codes up through the stack.
>
>Your particular device may have a different arrival protocol. I would
>recommend that you have your filter spit out a debug statement on every IRP
>that goes through your filter and watch what happens when the media
>arrives.
>You’ll be able to watch the results with either a debugger (WinDbg,
>SoftICE)
>or DebugView (see www.sysinternals.com or www.osr.com - I personally prefer
>the one from SysInternals (sorry, OSR)).
>
>My other concern is your comment about “spoofing” MBR data - are you trying
>to do this mount control at boot time? If so, would you mind sharing why?
>
> > If preventing Windows from mounting isn’t possible from
> > lower level Storage Filter Driver, may be we could just halt
> > driver stack building until some event occurs or IOCTL
> > arrives.
>
>PLEASE don’t try this. It will cause endless headaches not only for you,
>but for anyone using your software. Besides, you can’t really do that and
>have the system come up correctly. And what happens when the media arrives
>after the system is up?
>
> > Is there in Windows 2K/XP model any legal possibility to
> > halt driver stack building for a quite long period of time?
>
>No, there isn’t. And any “illegal” method will fail driver qualification
>AT
>LEAST. And it would be guaranteed to piss off the rest of the driver
>writing community. You don’t want that do you? Nah, I didn’t think so.
>
>Good luck!
>
>Stu Bell
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
file system is probably going to be your best approach here. otherwise
you could miss things like GESN (which we now use in some cases to
detect media changes), device specific quirks in the way they respond to
media arrivals, etc.
being a lower filter won’t keep all i/o requests from getting to the
device. ASPI (for example) goes around behind the disk driver’s back
and sends requests directly to the port driver’s FDO. These will never
be seen by your filter so unless you are very careful you could get into
an inconsistant state (user puts in restricted media, you block access,
user swaps media and ASPI sends a back-door request which swallows the
MCN, user can not read unrestricted media because your filter never sees
the change). ASPI still seems quite popular for all sorts of stuff so,
depending on the level of control you have over your operating
environment is you might need to worry abou it.
Presumably you want a lower filter in order to try and block everything
from seeing some pieces of media. If a lower filter still won’t get you
there then you might investigate how much work the FS approach is. Your
FS can examine the contents of the partition when called to mount and
determine if access should be restricted or not. If so then it stays
mounted and doesn’t grant read/write access to anyone (other, perhaps,
than your specific app). If access is to be granted then it fails the
mount operation such that other file systems will be given a chance to
recognize the disk. You could probably also mount on anything removable
& have a user-mode service which instructed the file system to dismount
& stay dismounted from a particular device until a media change was
detected.
writing a simple file system which only allows DASD access to the media
is probably not that hard. The RAW filesystem in NT is only about 3000
lines of code and it does much of what I think you’d want to do.
-p
-----Original Message-----
From: Shaggy Head [mailto:xxxxx@hotmail.com]
Sent: Wednesday, July 24, 2002 8:11 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.
Thanks, Stu.
It helps.
SH.
From: Stu Bell
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: How to avoid FS mounting.
>Date: Tue, 23 Jul 2002 12:27:30 -0600
>
> > We are able to “spoof” MBR data intercepting SRBs while
> > initializing. But it seems to us that this approach isn’t regular.
>
>Yup, you’re already too late. You need to look for the media arrival
>event.
>On CDs, this was usually an IRP_MJ_DEVICE_CONTROL with an
>IOCTL_SCSI_PASS_THROUGH or IOCTL_SCSI_PASS_THROUGH_DIRECT containing a
>TestUnitReady (0x00) command. When this changed from SC/ASC/ASCQ
5/3A/00
>to
>either 0/0/0 (no error) or 02/04/01 (Not Ready - becoming ready) or
>02/28/00
>(Not ready to change - medium may have arrived), THEN you need to start
>switching results back to the5/3A/00, along with the appropriate error
>settings. Other devices (Zip, PCMCIA disks, USB disks, …) MAY behave
the
>same, but you’d better assume that they don’t.
>
>You essentially want to convince the system that there is still NO
>MEDIA IN THE DRIVE. If you can do that, you can run your own little
>routines through a direct IOCTL connect to your filter and, when you
>deem it time, have the media “arrive” by sending the correct codes up
>through the stack.
>
>Your particular device may have a different arrival protocol. I would
>recommend that you have your filter spit out a debug statement on every
>IRP that goes through your filter and watch what happens when the media
>arrives. You’ll be able to watch the results with either a debugger
>(WinDbg,
>SoftICE)
>or DebugView (see www.sysinternals.com or www.osr.com - I personally
>prefer the one from SysInternals (sorry, OSR)).
>
>My other concern is your comment about “spoofing” MBR data - are you
>trying to do this mount control at boot time? If so, would you mind
>sharing why?
>
> > If preventing Windows from mounting isn’t possible from lower
> > level Storage Filter Driver, may be we could just halt driver stack
> > building until some event occurs or IOCTL arrives.
>
>PLEASE don’t try this. It will cause endless headaches not only for
>you, but for anyone using your software. Besides, you can’t really do
>that and have the system come up correctly. And what happens when the
>media arrives after the system is up?
>
> > Is there in Windows 2K/XP model any legal possibility to halt
> > driver stack building for a quite long period of time?
>
>No, there isn’t. And any “illegal” method will fail driver
>qualification
>AT
>LEAST. And it would be guaranteed to piss off the rest of the driver
>writing community. You don’t want that do you? Nah, I didn’t think
so.
>
>Good luck!
>
>Stu Bell
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com To
>unsubscribe send a blank email to %%email.unsub%%
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
If you are writing a filesystem be careful to ensure that your filesystem is
registered before the actual filesystem that might recognize the media.
Otherwis the real filesystem might accept the volume before your filesystem
gets a chance to take it or veto it. The way to do this is to register as a
filesystem as late in the game as possible (presumably as a system driver)
and by also not specifying DO_LOW_PRIORITY_FILESYSTEM. The IO manager goes
through a list of registered filesystem device object in the last inserted
first called order (only for non low priority filesystems).
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Peter Wieland” wrote in message
news:xxxxx@ntdev…
file system is probably going to be your best approach here. otherwise
you could miss things like GESN (which we now use in some cases to
detect media changes), device specific quirks in the way they respond to
media arrivals, etc.
being a lower filter won’t keep all i/o requests from getting to the
device. ASPI (for example) goes around behind the disk driver’s back
and sends requests directly to the port driver’s FDO. These will never
be seen by your filter so unless you are very careful you could get into
an inconsistant state (user puts in restricted media, you block access,
user swaps media and ASPI sends a back-door request which swallows the
MCN, user can not read unrestricted media because your filter never sees
the change). ASPI still seems quite popular for all sorts of stuff so,
depending on the level of control you have over your operating
environment is you might need to worry abou it.
Presumably you want a lower filter in order to try and block everything
from seeing some pieces of media. If a lower filter still won’t get you
there then you might investigate how much work the FS approach is. Your
FS can examine the contents of the partition when called to mount and
determine if access should be restricted or not. If so then it stays
mounted and doesn’t grant read/write access to anyone (other, perhaps,
than your specific app). If access is to be granted then it fails the
mount operation such that other file systems will be given a chance to
recognize the disk. You could probably also mount on anything removable
& have a user-mode service which instructed the file system to dismount
& stay dismounted from a particular device until a media change was
detected.
writing a simple file system which only allows DASD access to the media
is probably not that hard. The RAW filesystem in NT is only about 3000
lines of code and it does much of what I think you’d want to do.
-p
-----Original Message-----
From: Shaggy Head [mailto:xxxxx@hotmail.com]
Sent: Wednesday, July 24, 2002 8:11 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.
Thanks, Stu.
It helps.
SH.
>From: Stu Bell
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: How to avoid FS mounting.
>Date: Tue, 23 Jul 2002 12:27:30 -0600
>
> > We are able to “spoof” MBR data intercepting SRBs while
> > initializing. But it seems to us that this approach isn’t regular.
>
>Yup, you’re already too late. You need to look for the media arrival
>event.
>On CDs, this was usually an IRP_MJ_DEVICE_CONTROL with an
>IOCTL_SCSI_PASS_THROUGH or IOCTL_SCSI_PASS_THROUGH_DIRECT containing a
>TestUnitReady (0x00) command. When this changed from SC/ASC/ASCQ
5/3A/00
>to
>either 0/0/0 (no error) or 02/04/01 (Not Ready - becoming ready) or
>02/28/00
>(Not ready to change - medium may have arrived), THEN you need to start
>switching results back to the5/3A/00, along with the appropriate error
>settings. Other devices (Zip, PCMCIA disks, USB disks, …) MAY behave
the
>same, but you’d better assume that they don’t.
>
>You essentially want to convince the system that there is still NO
>MEDIA IN THE DRIVE. If you can do that, you can run your own little
>routines through a direct IOCTL connect to your filter and, when you
>deem it time, have the media “arrive” by sending the correct codes up
>through the stack.
>
>Your particular device may have a different arrival protocol. I would
>recommend that you have your filter spit out a debug statement on every
>IRP that goes through your filter and watch what happens when the media
>arrives. You’ll be able to watch the results with either a debugger
>(WinDbg,
>SoftICE)
>or DebugView (see www.sysinternals.com or www.osr.com - I personally
>prefer the one from SysInternals (sorry, OSR)).
>
>My other concern is your comment about “spoofing” MBR data - are you
>trying to do this mount control at boot time? If so, would you mind
>sharing why?
>
> > If preventing Windows from mounting isn’t possible from lower
> > level Storage Filter Driver, may be we could just halt driver stack
> > building until some event occurs or IOCTL arrives.
>
>PLEASE don’t try this. It will cause endless headaches not only for
>you, but for anyone using your software. Besides, you can’t really do
>that and have the system come up correctly. And what happens when the
>media arrives after the system is up?
>
> > Is there in Windows 2K/XP model any legal possibility to halt
> > driver stack building for a quite long period of time?
>
>No, there isn’t. And any “illegal” method will fail driver
>qualification
>AT
>LEAST. And it would be guaranteed to piss off the rest of the driver
>writing community. You don’t want that do you? Nah, I didn’t think
so.
>
>Good luck!
>
>Stu Bell
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com To
>unsubscribe send a blank email to %%email.unsub%%
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
Peter Wieland wrote…
being a lower filter won’t keep all i/o requests from getting to the
device. ASPI (for example) goes around behind the disk driver’s back
and sends requests directly to the port driver’s FDO…
The original poster said he had a lower filter on the SCSI driver rather
than the class driver. Even so, what you say makes sense.
Perhaps an upper filter on the SCSI driver would be better, since at that
point all of the calls will be SRBs and URBs instead of hardware controller
stuff dependent on the miniport implementation.
Even so, at least one CD-writing tool that I heard of ties into the stack as
a SCSI filter driver. That definitely limits the options if the original
poster is trying to support CD media.
writing a simple file system which only allows DASD access to
the media is probably not that hard. The RAW filesystem in NT
is only about 3000 lines of code and it does much of what I think
you’d want to do.
Cool - is there source on that in the IFS kit? If not, I would not
recommend it to a neophyte. The original poster did not seem to have much
background in driver writing (I could be wrong), so I was steering him away
from IFS. I certainly wouldn’t want an FS to be MY first intro to driver
writing!
Stu Bell
a “lower filter” is still above the PDO and still sees SRBs. There’s no
good way to insert yourself between the miniport and the hardware. If
he were to write an upper filter he would be loaded above the FDO and
thus would be unable to trap operations as they went up to the class
driver.
I wouldn’t normally want my first driver to be a file system, but that’s
because full-blown file systems are very complex. This wouldn’t be any
such thing. I do think it would be the best place for someone to block
mounts if they’re really not experienced with storage drivers, storage
devices, SCSI, tracking & updating the state of the device, backdoors
used by ASPI and the like, device specific inconsistancies in the way
they report new media, culling out false media change indications
(devices which report changes even though none occurred) and the general
architecture of the storage stack.
For an FS they only need to worry about one component.
-p
-----Original Message-----
From: Stu Bell [mailto:xxxxx@dataplay.com]
Sent: Friday, July 26, 2002 12:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.
Peter Wieland wrote…
being a lower filter won’t keep all i/o requests from getting to the
device. ASPI (for example) goes around behind the disk driver’s back
and sends requests directly to the port driver’s FDO…
The original poster said he had a lower filter on the SCSI driver rather
than the class driver. Even so, what you say makes sense.
Perhaps an upper filter on the SCSI driver would be better, since at
that point all of the calls will be SRBs and URBs instead of hardware
controller stuff dependent on the miniport implementation.
Even so, at least one CD-writing tool that I heard of ties into the
stack as a SCSI filter driver. That definitely limits the options if
the original poster is trying to support CD media.
writing a simple file system which only allows DASD access to
the media is probably not that hard. The RAW filesystem in NT
is only about 3000 lines of code and it does much of what I think
you’d want to do.
Cool - is there source on that in the IFS kit? If not, I would not
recommend it to a neophyte. The original poster did not seem to have
much background in driver writing (I could be wrong), so I was steering
him away from IFS. I certainly wouldn’t want an FS to be MY first intro
to driver writing!
Stu Bell
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
Let me see if I understand: He wants to prevent a disk from mounting
until a later point in time. One suggestion is to flag the media as
removable in the SCSI filter. On CHECK_VERIFY command, you can return a
status indicating no media.
If this is not suitable, simply return an error code on the SRBs that
will force Windows to mark the disk offline. Then through a special SRB
(vendor specific) you can tell the device to come on-line whenever you
want.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, July 26, 2002 12:56 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.
a “lower filter” is still above the PDO and still sees SRBs. There’s no
good way to insert yourself between the miniport and the hardware. If
he were to write an upper filter he would be loaded above the FDO and
thus would be unable to trap operations as they went up to the class
driver.
I wouldn’t normally want my first driver to be a file system, but that’s
because full-blown file systems are very complex. This wouldn’t be any
such thing. I do think it would be the best place for someone to block
mounts if they’re really not experienced with storage drivers, storage
devices, SCSI, tracking & updating the state of the device, backdoors
used by ASPI and the like, device specific inconsistancies in the way
they report new media, culling out false media change indications
(devices which report changes even though none occurred) and the general
architecture of the storage stack.
For an FS they only need to worry about one component.
-p
-----Original Message-----
From: Stu Bell [mailto:xxxxx@dataplay.com]
Sent: Friday, July 26, 2002 12:27 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.
Peter Wieland wrote…
being a lower filter won’t keep all i/o requests from getting to the
device. ASPI (for example) goes around behind the disk driver’s back
and sends requests directly to the port driver’s FDO…
The original poster said he had a lower filter on the SCSI driver rather
than the class driver. Even so, what you say makes sense.
Perhaps an upper filter on the SCSI driver would be better, since at
that point all of the calls will be SRBs and URBs instead of hardware
controller stuff dependent on the miniport implementation.
Even so, at least one CD-writing tool that I heard of ties into the
stack as a SCSI filter driver. That definitely limits the options if
the original poster is trying to support CD media.
writing a simple file system which only allows DASD access to
the media is probably not that hard. The RAW filesystem in NT
is only about 3000 lines of code and it does much of what I think
you’d want to do.
Cool - is there source on that in the IFS kit? If not, I would not
recommend it to a neophyte. The original poster did not seem to have
much background in driver writing (I could be wrong), so I was steering
him away from IFS. I certainly wouldn’t want an FS to be MY first intro
to driver writing!
Stu Bell
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
> Even so, at least one CD-writing tool that I heard of ties into the
stack as
a SCSI filter driver.
Adaptec/Roxio’s one. It install CDRAL drivers as both upper and lower
filters for CDROM.SYS.
Max
Yes, I (*ahem*) know. The upper filter is CDRAL, while the lower filter is
CDR4VSD. I didn’t consider these a “SCSI” filter because they’re not on the
SCSI class, per se, but on the CDROM class. The original poster said that
he had a lower SCSI filter, which I took to mean a lower filter driver on
the SCSI class driver.
Is my interpretation of this correct? It’s certainly the way I was taught
to interpret it.
The example I had in mind was Nero CD-Burning, which I believe installs an
upper filter on the SCSI class driver. Eeew!
Stu
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Saturday, July 27, 2002 11:25 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How to avoid FS mounting.> Even so, at least one CD-writing tool that I heard of ties into the
stack as
> a SCSI filter driver.Adaptec/Roxio’s one. It install CDRAL drivers as both upper and lower
filters for CDROM.SYS.Max
> a “lower filter” is still above the PDO and still sees SRBs. There’s no
good way to insert yourself between the miniport and the hardware. If
he were to write an upper filter he would be loaded above the FDO and
thus would be unable to trap operations as they went up to the class
driver.
I hadn’t thought about this – good point, Peter.
I wouldn’t normally want my first driver to be a file system,
but that’s
because full-blown file systems are very complex. This
wouldn’t be any
such thing. I do think it would be the best place for
someone to block
mounts if they’re really not experienced with storage drivers, storage
devices, SCSI, tracking & updating the state of the device, backdoors
used by ASPI and the like, device specific inconsistancies in the way
they report new media, culling out false media change indications
(devices which report changes even though none occurred) and
the general
architecture of the storage stack.For an FS they only need to worry about one component.
Maybe I’ve never gone this way since I’ve always had to worry about a
“full-blown” file system anyway - why write yet another one? Even so, an
interesting point.
The original poster has since quietly ducked his head down, so we’re not
quite sure WHAT he was trying to do.
Thanks for responding Peter (and Max!). I always learn a lot from all the
correspondents to this list, as long we’re not talking about C versus C++
(AUUGH! Not that again! 
Stu
> Yes, I (*ahem*) know. The upper filter is CDRAL, while the lower
filter is
CDR4VSD.
Do you have a problem with CD drive disappearing after awaken from
hibernation?
Max
> Thanks for responding Peter (and Max!). I always learn a lot from
all the
correspondents to this list, as long we’re not talking about C
versus C++
(AUUGH! Not that again!
Yes. No time for this.
Max
> > Yes, I (*ahem*) know. The upper filter is CDRAL, while the lower
> filter is CDR4VSD.
Do you have a problem with CD drive disappearing after awaken from
hibernation?
First, a disclaimer: I do not work for Adaptec or Roxio, so I cannot
comment about how their code currently works.
And now an admission: I used to work for them, and was involved with the
above pieces of code. I hope I don’t come to regret that admission. 
We did have some problems with hibernation. We solved many of them while I
was there. Most of the problems were our drivers preventing the system from
going into hibernation, which resulted from IRPs that were being mis-handled
(hanging IRPs and such). When I was there, we were able to go into and come
out of hibernation, although there were some “outlying” cases that didn’t
work. Since then, they may have solved all of the problems – I don’t know.
If the drive is gone when the system comes out of hibernation, I would guess
that the PNP routines are not handling things properly. IIRC, PNP
essentially tore us down before going into hibernation and then built us
back up again when we came out of hibernation. Getting all those ducks in a
row called for being painstakingly correct in the PNP routines.
If you’re having a problem here, instrument the heck out of your code and
use WinDbg. Make sure that EVERY IRP you handle is being handled correctly
(even ones that you don’t think are supposed to be handled by your driver).
Make sure you follow the PNP protocols to the letter. There ain’t no other
way.
Stu
> We did have some problems with hibernation. We solved many of them
while I
was there. Most of the problems were our drivers preventing the
system from
going into hibernation, which resulted from IRPs that were being
mis-handled
(hanging IRPs and such). When I was there, we were able to go into
and come
out of hibernation, although there were some “outlying” cases that
didn’t
The problem was:
I hope the new version have fixed this.
Max