Virtual Storport: ejecting media? (safely)

I’ve been writing a Virtual Storport miniport driver and I want to ensure that any mounted volumes have been properly flushed before disconnecting the virtual disk. I figured that mimicing an ‘eject button’ for removable media would be the way to go - telling Windows to flush it out and then handling the correponding SCSIOP_MEDIUM_REMOVAL and SCSIOP_START_STOP_UNIT operations. Indeed when I eject using the Windows GUI - this works fine.

However, I am trying to get the miniport driver itself to tell Windows that an ‘eject’ button was pressed, and for that I get the following behaviour:

  1. Despite setting the ScsiStatus to SCSISTAT_CHECK_CONDITION in SRB responses, there are no SCSIOP_REQUEST_SENSE queries received by the driver - in fact I never see these queries occur at any time throughout driver usage… this seems really strange to me as I thought these are ordinarily triggered…

(** Does anyone know how I can trigger a SCSIOP REQUEST_SENSE? **)

  1. Regardless, I’ve also tried setting the SrbStatus to have SRB_STATUS_AUTOSENSE_VALID and set the sense as:
    SenseKey = SCSI_SENSE_UNIT_ATTENTION
    AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
    AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
    AdditionalSenseLength = 14; // no additional length beyond main fields

I figure this might not be working because it is not a response to a SCSIOP_REQUEST_SENSE - but to other operations instead?

Am I missing something? What could I be doing wrong? Or is there another way to safely flush data from the driver before disconnecting it?

Any help would be appreciated.

Thanks,
Dan

I think you have to declare the media as removable from the moment it
arrives, rather than deciding that it needs to become removable after it
has been made visible to the system.

Mark Roddy

On Fri, Jan 25, 2013 at 2:36 PM, wrote:

> I’ve been writing a Virtual Storport miniport driver and I want to ensure
> that any mounted volumes have been properly flushed before disconnecting
> the virtual disk. I figured that mimicing an ‘eject button’ for removable
> media would be the way to go - telling Windows to flush it out and then
> handling the correponding SCSIOP_MEDIUM_REMOVAL and SCSIOP_START_STOP_UNIT
> operations. Indeed when I eject using the Windows GUI - this works fine.
>
> However, I am trying to get the miniport driver itself to tell Windows
> that an ‘eject’ button was pressed, and for that I get the following
> behaviour:
>
> 1. Despite setting the ScsiStatus to SCSISTAT_CHECK_CONDITION in SRB
> responses, there are no SCSIOP_REQUEST_SENSE queries received by the driver
> - in fact I never see these queries occur at any time throughout driver
> usage… this seems really strange to me as I thought these are ordinarily
> triggered…
>
> ( Does anyone know how I can trigger a SCSIOP REQUEST_SENSE? )
>
> 2. Regardless, I’ve also tried setting the SrbStatus to have
> SRB_STATUS_AUTOSENSE_VALID and set the sense as:
> SenseKey = SCSI_SENSE_UNIT_ATTENTION
> AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
> AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
> AdditionalSenseLength = 14; // no additional length beyond main fields
>
> I figure this might not be working because it is not a response to a
> SCSIOP_REQUEST_SENSE - but to other operations instead?
>
> Am I missing something? What could I be doing wrong? Or is there another
> way to safely flush data from the driver before disconnecting it?
>
> Any help would be appreciated.
>
> Thanks,
> Dan
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Thank you Mark. That is indeed what I do, I set the per LUN removable media flags as such - and eject works fine when ejecting directly from the Windows GUI. It’s just that I can’t seem to initiate an eject from the driver itself.

On 25/01/2013, at 8:09 PM, Mark Roddy wrote:

I think you have to declare the media as removable from the moment it arrives, rather than deciding that it needs to become removable after it has been made visible to the system.

Mark Roddy

On Fri, Jan 25, 2013 at 2:36 PM, wrote:
> I’ve been writing a Virtual Storport miniport driver and I want to ensure that any mounted volumes have been properly flushed before disconnecting the virtual disk. I figured that mimicing an ‘eject button’ for removable media would be the way to go - telling Windows to flush it out and then handling the correponding SCSIOP_MEDIUM_REMOVAL and SCSIOP_START_STOP_UNIT operations. Indeed when I eject using the Windows GUI - this works fine.
>
> However, I am trying to get the miniport driver itself to tell Windows that an ‘eject’ button was pressed, and for that I get the following behaviour:
>
> 1. Despite setting the ScsiStatus to SCSISTAT_CHECK_CONDITION in SRB responses, there are no SCSIOP_REQUEST_SENSE queries received by the driver - in fact I never see these queries occur at any time throughout driver usage… this seems really strange to me as I thought these are ordinarily triggered…
>
> ( Does anyone know how I can trigger a SCSIOP REQUEST_SENSE? )
>
> 2. Regardless, I’ve also tried setting the SrbStatus to have SRB_STATUS_AUTOSENSE_VALID and set the sense as:
> SenseKey = SCSI_SENSE_UNIT_ATTENTION
> AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
> AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
> AdditionalSenseLength = 14; // no additional length beyond main fields
>
> I figure this might not be working because it is not a response to a SCSIOP_REQUEST_SENSE - but to other operations instead?
>
> Am I missing something? What could I be doing wrong? Or is there another way to safely flush data from the driver before disconnecting it?
>
> Any help would be appreciated.
>
> Thanks,
> Dan
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> — NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

>It’s just that I can’t seem to initiate an eject from the driver itself.

How can you do this? this will leave unflushed caches and data corruption.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Ah, so yes you cannot ‘eject’ from the driver as eject starts from user
mode. What you can do is initiate surprise removal. If you have correctly
marked the media as removable then the FS above you will make sure that the
volume is kept consistent even if the media disappears underneath it.

Just convince pnp to reenumerate the bus and don’t provide inquiry data for
this lun.

Mark Roddy

On Fri, Jan 25, 2013 at 3:34 PM, Dan Greenfield wrote:

> Thank you Mark. That is indeed what I do, I set the per LUN removable
> media flags as such - and eject works fine when ejecting directly from the
> Windows GUI. It’s just that I can’t seem to initiate an eject from the
> driver itself.
>
>
> On 25/01/2013, at 8:09 PM, Mark Roddy wrote:
>
> I think you have to declare the media as removable from the moment it
> arrives, rather than deciding that it needs to become removable after it
> has been made visible to the system.
>
> Mark Roddy
>
>
> On Fri, Jan 25, 2013 at 2:36 PM, wrote:
>
>> I’ve been writing a Virtual Storport miniport driver and I want to ensure
>> that any mounted volumes have been properly flushed before disconnecting
>> the virtual disk. I figured that mimicing an ‘eject button’ for removable
>> media would be the way to go - telling Windows to flush it out and then
>> handling the correponding SCSIOP_MEDIUM_REMOVAL and SCSIOP_START_STOP_UNIT
>> operations. Indeed when I eject using the Windows GUI - this works fine.
>>
>> However, I am trying to get the miniport driver itself to tell Windows
>> that an ‘eject’ button was pressed, and for that I get the following
>> behaviour:
>>
>> 1. Despite setting the ScsiStatus to SCSISTAT_CHECK_CONDITION in SRB
>> responses, there are no SCSIOP_REQUEST_SENSE queries received by the driver
>> - in fact I never see these queries occur at any time throughout driver
>> usage… this seems really strange to me as I thought these are ordinarily
>> triggered…
>>
>> ( Does anyone know how I can trigger a SCSIOP REQUEST_SENSE? )
>>
>> 2. Regardless, I’ve also tried setting the SrbStatus to have
>> SRB_STATUS_AUTOSENSE_VALID and set the sense as:
>> SenseKey = SCSI_SENSE_UNIT_ATTENTION
>> AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
>> AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
>> AdditionalSenseLength = 14; // no additional length beyond main fields
>>
>> I figure this might not be working because it is not a response to a
>> SCSIOP_REQUEST_SENSE - but to other operations instead?
>>
>> Am I missing something? What could I be doing wrong? Or is there another
>> way to safely flush data from the driver before disconnecting it?
>>
>> Any help would be appreciated.
>>
>> Thanks,
>> Dan
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Hi Maxim, there are real-world SCSI devices that have a physical eject button. When this is pressed the driver informs the OS of the user’s intent and the OS then flush caches and ejects the drive. What I’ve tried to do is simulate the SCSI code for virtually ‘pressing’ this eject button by informing the OS that it was pressed. However, despite setting the sense flag, I can’t seem to trigger Windows to issue a SCSIOP REQUEST_SENSE.

On 27/01/2013, at 6:44 PM, Maxim S. Shatskih wrote:

> It’s just that I can’t seem to initiate an eject from the driver itself.

How can you do this? this will leave unflushed caches and data corruption.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Thanks Mark, as I just replied to Maxim now, I’m trying to simulate a fake eject button being pressed by the user on the device. SCSI does support ejectable media buttons in this manner (see point 2 for the Sense parameters that should be set). What I’m having trouble with is getting Windows to issue a SCSIOP REQUEST_SENSE despite setting the SCSISTAT_CHECK_CONDITION. Do you have any ideas on how to get one triggered?

On 27/01/2013, at 6:50 PM, Mark Roddy wrote:

Ah, so yes you cannot ‘eject’ from the driver as eject starts from user mode. What you can do is initiate surprise removal. If you have correctly marked the media as removable then the FS above you will make sure that the volume is kept consistent even if the media disappears underneath it.

Just convince pnp to reenumerate the bus and don’t provide inquiry data for this lun.

Mark Roddy

On Fri, Jan 25, 2013 at 3:34 PM, Dan Greenfield wrote:
> Thank you Mark. That is indeed what I do, I set the per LUN removable media flags as such - and eject works fine when ejecting directly from the Windows GUI. It’s just that I can’t seem to initiate an eject from the driver itself.
>
>
> On 25/01/2013, at 8:09 PM, Mark Roddy wrote:
>
>> I think you have to declare the media as removable from the moment it arrives, rather than deciding that it needs to become removable after it has been made visible to the system.
>>
>> Mark Roddy
>>
>>
>> On Fri, Jan 25, 2013 at 2:36 PM, wrote:
>> I’ve been writing a Virtual Storport miniport driver and I want to ensure that any mounted volumes have been properly flushed before disconnecting the virtual disk. I figured that mimicing an ‘eject button’ for removable media would be the way to go - telling Windows to flush it out and then handling the correponding SCSIOP_MEDIUM_REMOVAL and SCSIOP_START_STOP_UNIT operations. Indeed when I eject using the Windows GUI - this works fine.
>>
>> However, I am trying to get the miniport driver itself to tell Windows that an ‘eject’ button was pressed, and for that I get the following behaviour:
>>
>> 1. Despite setting the ScsiStatus to SCSISTAT_CHECK_CONDITION in SRB responses, there are no SCSIOP_REQUEST_SENSE queries received by the driver - in fact I never see these queries occur at any time throughout driver usage… this seems really strange to me as I thought these are ordinarily triggered…
>>
>> ( Does anyone know how I can trigger a SCSIOP REQUEST_SENSE? )
>>
>> 2. Regardless, I’ve also tried setting the SrbStatus to have SRB_STATUS_AUTOSENSE_VALID and set the sense as:
>> SenseKey = SCSI_SENSE_UNIT_ATTENTION
>> AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
>> AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
>> AdditionalSenseLength = 14; // no additional length beyond main fields
>>
>> I figure this might not be working because it is not a response to a SCSIOP_REQUEST_SENSE - but to other operations instead?
>>
>> Am I missing something? What could I be doing wrong? Or is there another way to safely flush data from the driver before disconnecting it?
>>
>> Any help would be appreciated.
>>
>> Thanks,
>> Dan
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>> — NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> — NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

It could be you ARE successfully responding to cause an eject request. And the storage stacks says “sorry, files are open, so can’t eject right now”. LOTS of apps can’t respond to PnP eject requests on an open file, because they have not even registered to receive notification. When the file system is unable to convince apps to close their files on the mounted volume, the eject request is essentially canceled.

Also just look at the scenario of a memory mapped file, what as the graceful way to eject that. You can’t just make some range of addresses vanish or suddenly become read-only.

The media we most commonly think of with an eject button is a DVD drive, and the consequences of ejecting read-only media are different that the consequences of ejecting read-write media.

Keep in mind ejecting the media is different that the device going away. When you press the eject button on a DVD drive, the DVD drive does not go away.

You might trace the SCSI commands and see if you get a command to lock the media, which would mean an eject button does not work until an unlock is received.

Perhaps the correct question to ask is: how do people implement hot plug disks on Windows. Generally I think there is a user command initiated from the top before the disk is removed. Some hot plug disks have a physical lock controlled by the OS, so you can’t pull the disk unless it’s been properly unmounted. Removing a hot plug disk is the device going away, not just it’s media.

You might write/find a little test app that opens a file on a volume, registers for PnP notification on that file, and then you can see of you get notification when you issue eject requests from the driver. I’d bet there is a ETW trace you could enable to show what’s happening.

As I remember, a few years ago when I tried to get storage devices to gracefully eject from the driver, I gave up and concluded ungraceful removal was the only thing that worked reliably. Having something that sometimes maybe would gracefully eject was not very useful.

Jan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Greenfield
Sent: Sunday, January 27, 2013 11:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Virtual Storport: ejecting media? (safely)

Thanks Mark, as I just replied to Maxim now, I’m trying to simulate a fake eject button being pressed by the user on the device. SCSI does support ejectable media buttons in this manner (see point 2 for the Sense parameters that should be set). What I’m having trouble with is getting Windows to issue a SCSIOP REQUEST_SENSE despite setting the SCSISTAT_CHECK_CONDITION. Do you have any ideas on how to get one triggered?

On 27/01/2013, at 6:50 PM, Mark Roddy wrote:

Ah, so yes you cannot ‘eject’ from the driver as eject starts from user mode. What you can do is initiate surprise removal. If you have correctly marked the media as removable then the FS above you will make sure that the volume is kept consistent even if the media disappears underneath it.

Just convince pnp to reenumerate the bus and don’t provide inquiry data for this lun.

Mark Roddy

On Fri, Jan 25, 2013 at 3:34 PM, Dan Greenfield > wrote:
Thank you Mark. That is indeed what I do, I set the per LUN removable media flags as such - and eject works fine when ejecting directly from the Windows GUI. It’s just that I can’t seem to initiate an eject from the driver itself.

On 25/01/2013, at 8:09 PM, Mark Roddy wrote:

I think you have to declare the media as removable from the moment it arrives, rather than deciding that it needs to become removable after it has been made visible to the system.

Mark Roddy

On Fri, Jan 25, 2013 at 2:36 PM, > wrote:
I’ve been writing a Virtual Storport miniport driver and I want to ensure that any mounted volumes have been properly flushed before disconnecting the virtual disk. I figured that mimicing an ‘eject button’ for removable media would be the way to go - telling Windows to flush it out and then handling the correponding SCSIOP_MEDIUM_REMOVAL and SCSIOP_START_STOP_UNIT operations. Indeed when I eject using the Windows GUI - this works fine.

However, I am trying to get the miniport driver itself to tell Windows that an ‘eject’ button was pressed, and for that I get the following behaviour:

1. Despite setting the ScsiStatus to SCSISTAT_CHECK_CONDITION in SRB responses, there are no SCSIOP_REQUEST_SENSE queries received by the driver - in fact I never see these queries occur at any time throughout driver usage… this seems really strange to me as I thought these are ordinarily triggered…

( Does anyone know how I can trigger a SCSIOP REQUEST_SENSE? )

2. Regardless, I’ve also tried setting the SrbStatus to have SRB_STATUS_AUTOSENSE_VALID and set the sense as:
SenseKey = SCSI_SENSE_UNIT_ATTENTION
AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
AdditionalSenseLength = 14; // no additional length beyond main fields

I figure this might not be working because it is not a response to a SCSIOP_REQUEST_SENSE - but to other operations instead?

Am I missing something? What could I be doing wrong? Or is there another way to safely flush data from the driver before disconnecting it?

Any help would be appreciated.

Thanks,
Dan


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

>the driver informs the OS of the user’s intent and the OS then flush caches and ejects the drive.

I think that, in such a case (the OS informed about eject), the device’s button does not do any actual eject. Instead, it informs the OS about it.

I think there was some SCSI event (yes, SCSI has events, read about them) about the button press. Your driver should correctly handle this event.

Also, there is “prevent/allow medium removal” stuff. If “prevent medium removal” is set, then your button must not do the actual eject, only send the SCSI event to the host.

Also, if you’re writing files to formatted BD-RE/DVD-RAM, and press the drive’s eject button, I think that no cache flushes are done in this case. So, I have doubts that Windows supports such flushes out of the box.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>Just convince pnp to reenumerate the bus and don’t provide inquiry data for this lun.

This is surprise removal. No cache flushes are done in this case.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>SCSIOP REQUEST_SENSE despite setting the SCSISTAT_CHECK_CONDITION.

If your driver has AutoRequestSense, then IIRC this is never sent, and you should fill the sense info in the SRB instead.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>The media we most commonly think of with an eject button is a DVD drive

Think DVD-RAM or BD-RE, with such media, you can high-level-format it to FAT32 and just copy the files there.

What about pressing the drive’s eject button during the copy? I don’t think flushes are done.

Also, FASTFAT and CDROM sources are in the (old) WDK, so one can investigate this question in details using the source.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Thanks Maxim. It appears that with Storport, the AutoRequestSense is always enabled. This means that the virtual eject button press event I am sending is simply being ignored.

I have to wonder how ejectable tape drives, zip drives and other ejectable media cope, but perhaps they simply don’t use storport for this.

On 27/01/2013, at 9:07 PM, Maxim S. Shatskih wrote:

> SCSIOP REQUEST_SENSE despite setting the SCSISTAT_CHECK_CONDITION.

If your driver has AutoRequestSense, then IIRC this is never sent, and you should fill the sense info in the SRB instead.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

If the media has been correctly indicated as removable all writes are write
through. See usbdisk.

Mark Roddy

On Sun, Jan 27, 2013 at 4:06 PM, Maxim S. Shatskih
wrote:

> >Just convince pnp to reenumerate the bus and don’t provide inquiry data
> for this lun.
>
> This is surprise removal. No cache flushes are done in this case.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

>Thanks Maxim. It appears that with Storport, the AutoRequestSense is always enabled. This means

that the virtual eject button press event I am sending is simply being ignored.

How is AutoRequestSense related to eject button?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Hmmmm…

As Mr. Bottorff implied, I think you (OP) may be confusing two different Windows constructs: Removable MEDIA and removable DEVICES. They are different.

Oh, they most certainly do. But they’re ejecting the MEDIA. The drive (LUN) remains.

I think this is where you may be getting your wires cross with the (very good) advice some of the experts have been giving you here. Having an LU disappear is merely surprise removal, as Mr. Shatskih said.

Further, different file systems treat removable MEDIA and removable DRIVES differently. I seem to recall at one point NTFS did not support removable media, because it did not do write-through of all its data… whereas FAT did. I have no clue if that’s still the case.

Peter
OSR

> the virtual eject button press event I am sending is simply being ignored.

Two questions:

  1. What SCSI command are you reporting it on? Be specific.
  2. Has Windows put the media in the prevent removal state?

Thank you Peter. I do realise that there are both - and I have purposefully made the media ejectable but the device not. I require the media to be ejected not the LUN - the LUN should indeed remain until I decide to issue a surprise removal of the LUN at some later stage. The problem is that I cannot find a way to safely eject the media(s) for a specific LUN!

On 29/01/2013, at 5:00 AM, Windows System Software Devs Interest List digest wrote:

Subject: RE: Virtual Storport: ejecting media? (safely)
From: xxxxx@osr.com
Date: Mon, 28 Jan 2013 16:03:07 -0500 (EST)
X-Message-Number: 38

Hmmmm…

As Mr. Bottorff implied, I think you (OP) may be confusing two different Windows constructs: Removable MEDIA and removable DEVICES. They are different.

Oh, they most certainly do. But they’re ejecting the MEDIA. The drive (LUN) remains.

I think this is where you may be getting your wires cross with the (very good) advice some of the experts have been giving you here. Having an LU disappear is merely surprise removal, as Mr. Shatskih said.

Further, different file systems treat removable MEDIA and removable DRIVES differently. I seem to recall at one point NTFS did not support removable media, because it did not do write-through of all its data… whereas FAT did. I have no clue if that’s still the case.

Peter
OSR


Apologies - I used the wrong subject header in responding. Re-sending with the correct subject header…

As per my original post, I am providing a SCSI event by filling out sense key data that mimics the SCSI Lun requesting an eject of it’s media, namely:
SenseKey = SCSI_SENSE_UNIT_ATTENTION
AdditionalSenseCode = SCSI_ADSENSE_OPERATOR_REQUEST
AdditionalSenseCodeQualifier = SCSI_SENSEQ_MEDIUM_REMOVAL
AdditionalSenseLength = 14; // no additional length beyond main fields

However, this SCSI event is being ignored. I had thought that it was because an explicit SCSIOP_REQUEST_SENSE was not being issued by to the miniport driver, but given that AutoRequestSense is always on for Storport (I found a reference confirming this), it means that the event is merely being ignored.

On 29/01/2013, at 5:00 AM, Windows System Software Devs Interest List digest wrote:

Subject: Re: Virtual Storport: ejecting media? (safely)
From: “Maxim S. Shatskih”
> Date: Mon, 28 Jan 2013 19:49:06 +0400
> X-Message-Number: 26
>
>> Thanks Maxim. It appears that with Storport, the AutoRequestSense is always enabled. This means
>> that the virtual eject button press event I am sending is simply being ignored.
>
> How is AutoRequestSense related to eject button?
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com

Hi Sven, to answer your question:

  1. As I’ve become increasingly frustrated - all of them and have even tried triggering a BusChangeDetected so that Storport will issue more ops. Just to double check - what I see in particular are:
    SCSIOP_TEST_UNIT_READY (essentially pinging the device regularly)
    SCSIOP_INQUIRY
    SCSIOP_REPORT_LUNS

  2. I do track SCSIOP_MEDIUM_REMOVAL, and it does alternate between removable and non-removable states as the volume is used and idle. This does *suggest* that Windows does lock the drive when it needs to write to the volume and unlocks it at other times. However even with the medium in the unlocked state, the eject event is ignored…

On 29/01/2013, at 5:00 AM, Windows System Software Devs Interest List digest wrote:

Subject: RE: Virtual Storport: ejecting media? (safely)
From: xxxxx@gmail.com
Date: Mon, 28 Jan 2013 19:21:30 -0500 (EST)
X-Message-Number: 42

> the virtual eject button press event I am sending is simply being ignored.

Two questions:

  1. What SCSI command are you reporting it on? Be specific.
  2. Has Windows put the media in the prevent removal state?