From: David J. Craig on
With Windows 2000 we discovered that when writing 64MB to a SmartMedia
(128MB) card the media would be very busy for a while. Then the activity
would stop and it would appear that all was done. Then after 20 to 30
seconds after the last activity there would be another burst of activity.
If you removed the media before that without using an eject or remove from
within the OS, you would discover that the system areas of the FAT file
system were not updated and all the files were present but without any
directory entries for them. XP seems to have removed that delay.

Don't forget that there are two removables involved with some drives,
especially USB. You can have a removable drive and you can have removable
media. A USB floppy, and most flash memory readers have both. In some ways
USB based flash memory readers are almost like an old standard 3.5" floppy.
Neither has a drive that can tell the controller something has happened.
You can poll a USB device, but trying that with a floppy would burn out the
motor in a few months. I like SCSI, but it is too expensive and very few
vendors remain in that arena. It has a multiple initiator system where any
device can send to any other device (the controller is just another device).
Sure solves some of the problems.

"Uwe Sieber" <mail(a)uwe-sieber.de> wrote in message
news:511573F1hianqU1(a)mid.individual.net...
> David J. Craig wrote:
>> With XP there is an option to optimize media for speed and not safe
>> removabililty so I am not sure it an speed optimized drive will properly
>> flush.
>
> I've never seen even a minimal difference in caching behavour
> resulting from this settings for drives with drive type
> DRIVE_REMOVABLE. Have you?
>
>
> Uwe


From: Echo on
I see.

Thanks a lot!

Regards,
Echo

"Uwe Sieber" wrote:

>
> Some of these PCI attached card readers appear with a drive
> type DRIVE_UNKNOWN. Maybe because the drive developers had
> no fun, time or budget to implement the removable specific stuff
> like IOCTL_STORAGE_EJECT_MEDIA. So, I've been wrong calling
> such devices 'scrap devices'. It's the fault or their drivers.
>
> Try to open the storage volume with read+write and no share access.
> This requires admin previleges...
> If this succeeds, call FlushFileBuffers, DeviceIoControl with
> FSCTL_LOCK_VOLUME and then with FSCTL_DISMOUNT_VOLUME.
> Now you can tell the user that it's save now to take out the card.
> Check periodically if you can read some bytes from the media -
> FSCTL_DISMOUNT_VOLUME again each time.
> As soon as it fails, the media is gone and you can close the handle.
> Instead of polling, waiting for GUID_IO_MEDIA_REMOVAL it the
> better way but I do not expect that this works with this kind of
> underdone driver.
>
> Uwe
>
>
> Echo wrote:
> > I mean, FlashMedia Card, such as SdCard, sometimes can't be ejected by
> > IOCTL_STORAGE_EJECT_MEDIA.
> >
> > Echo
> >
> > "Uwe Sieber" wrote:
> >
> >>
> >> What do you mean with "can't work with"? Is it one of these
> >> scrap devices with GetDriveType returns DRIVE_UNKNOWN for?
> >>
> >> Uwe
> >>
> >>
> >> Echo wrote:
> >>> Some are PCI attached, some are internal usb attached. I tried many. Some can
> >>> be ejected with IOCTL_STORAGE_EJECT_MEDIA, FSCTL_DISMOUNT_VOLUME, some
> >>> can't. As to current one I'm testing, it's PCI attached, and can't work with
> >>> IOCTL_STORAGE_EJECT_MEDIA, FSCTL_DISMOUNT_VOLUME.
> >>>
> >>> I refer to MS KB article: http://support.microsoft.com/kb/165721 when using
> >>> IOCTL_STORAGE_EJECT_MEDIA method.
> >>>
> >>> Thanks & Regards,
> >>> Echo
> >>>
> >>> "Uwe Sieber" wrote:
> >>>
> >>>> With 'SdCard' you mean a PCI attached SD card reader? Then
> >>>> you have luck to get it back by means of "Scan for hardware
> >>>> changes". It would not work that way with an internal USB
> >>>> card reader.
> >>>> Here the right way is to eject the media using
> >>>> IOCTL_STORAGE_EJECT_MEDIA.
> >>>>
> >>>>
> >>>> Uwe
> >>>>
> >>>>
> >>>> Echo wrote:
> >>>>> I tried the project, it works well with usb devices (calling
> >>>>> CM_Request_Device_Eject), but has problem with fixed drive such as SdCard
> >>>>> (calling CM_Query_And_Remove_SubTree). SdCard can be ejected, but can't be
> >>>>> recognized after reinsertion. I have to "Scan for hardware changes" in
> >>>>> Control Panel to force system to find the device.
> >>>>>
> >>>>> Thanks & Regards,
> >>>>> Echo
> >>>>>
> >>>>> "Uwe Sieber" wrote:
> >>>>>
> >>>>>> Some are a bit hidden in too much text...
> >>>>>> If you want to program it yourself, here is my demo project:
> >>>>>> http://www.codeproject.com/system/RemoveDriveByLetter.asp
> >>>>>>
> >>>>>>
> >>>>>> It uses CM_Query_And_Remove_SubTree to remove the USB device.
> >>>>>> But this function requires admin previleges while
> >>>>>> CM_Request_Device_Eject works without. No idea why.
> >>>>>>
> >>>>>>
> >>>>>> Uwe
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Echo wrote:
> >>>>>>> Thanks a lot!
> >>>>>>>
> >>>>>>> I got what I want! And many useful tools!
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Echo
> >>>>>>>
> >>>>>>>
> >>>>>>> "Pavel A." wrote:
> >>>>>>>
> >>>>>>>> Look at http://www.uwe-sieber.de/
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> --PA
> >>>>>>>>
> >>>>>>>> "Echo" wrote:
> >>>>>>>>> Removable devices, such as usb devices, flashmedia card, can only be safely
> >>>>>>>>> removed by clicking the icon in system tray in WinXP. But how to make it
> >>>>>>>>> programmatically?
> >>>>>>>>>
> >>>>>>>>> I tried IOCTL_STORAGE_EJECT_MEDIA, FSCTL_DISMOUNT_VOLUME, but only have
> >>>>>>>>> effect in several special cases.
> >>>>>>>>>
> >>>>>>>>> Any advice be appreciated!
> >>>>>>>>>
> >>>>>>>>>
>
From: Uwe Sieber on

> With Windows 2000 we discovered that when writing 64MB to a SmartMedia
> (128MB) card the media would be very busy for a while.

Yes, W2K has an effective write cache activated even for FAT
formatted DRIVE_REMOVABLE drives. Therefore it blames the
user when an USB drive is removed unprepared.

> XP seems to have removed that delay.

XP hasn't only removed that delay, it has removed the write
caching for FAT formatted DRIVE_REMOVABLE drives (nearly) at
all. And the settings you menitioned have no effect on caching.
Nonetheless everyone seems to belive in them.

I had put together my findings some time ago:
http://www.uwe-sieber.de/usbstick_e.html


> Neither has a drive that can tell the controller something has
> happened.

Well designed USB card readers can. Under XP you can register
for getting GUID_IO_MEDIA_ARRIVAL / GUID_IO_MEDIA_REMOVAL events.
W2K doesn't support this.


Uwe



David J. Craig wrote:
> With Windows 2000 we discovered that when writing 64MB to a SmartMedia
> (128MB) card the media would be very busy for a while. Then the activity
> would stop and it would appear that all was done. Then after 20 to 30
> seconds after the last activity there would be another burst of activity.
> If you removed the media before that without using an eject or remove from
> within the OS, you would discover that the system areas of the FAT file
> system were not updated and all the files were present but without any
> directory entries for them. XP seems to have removed that delay.
>
> Don't forget that there are two removables involved with some drives,
> especially USB. You can have a removable drive and you can have removable
> media. A USB floppy, and most flash memory readers have both. In some ways
> USB based flash memory readers are almost like an old standard 3.5" floppy.
> Neither has a drive that can tell the controller something has happened.
> You can poll a USB device, but trying that with a floppy would burn out the
> motor in a few months. I like SCSI, but it is too expensive and very few
> vendors remain in that arena. It has a multiple initiator system where any
> device can send to any other device (the controller is just another device).
> Sure solves some of the problems.
>
> "Uwe Sieber" <mail(a)uwe-sieber.de> wrote in message
> news:511573F1hianqU1(a)mid.individual.net...
>> David J. Craig wrote:
>>> With XP there is an option to optimize media for speed and not safe
>>> removabililty so I am not sure it an speed optimized drive will properly
>>> flush.
>> I've never seen even a minimal difference in caching behavour
>> resulting from this settings for drives with drive type
>> DRIVE_REMOVABLE. Have you?
>>
>>
>> Uwe
>
>