Not able to disable disk write cache

Our system is running XP Embedded with Service Pack 1. We have attempted to
disable the hard disk write cache to help reduce corrupt disk writes in the
event the user powers off the system (we have no control on power off and do
not have any battery backup capability). We have used the control panel –
system – hardware – disk drives – properties – and unchecked the “Enable
write caching on the disk†setting. However, files are being written as if
the disk cache is still enabled. We have seen the disk writes take up to 14
seconds on FAT32 file system and about 3 seconds to actually get written to
disk. We have also tried to use the DISKCACHE.EXE tool with the same results.

Is the disabling of disk cache setting not working with XP Embedded? Is
there a workaround that can be used to enforce this or could there be a
component missing that is needed to make this work?

Thanks!

 

Hi Bruce,

You will have to switch to "optimize for quick removal". (If you can't then you will have to force it in registry)

Regards,
Slobodan

"BruceKrautbauer" <> wrote in message news:...
> Our system is running XP Embedded with Service Pack 1. We have attempted to
> disable the hard disk write cache to help reduce corrupt disk writes in the
> event the user powers off the system (we have no control on power off and do
> not have any battery backup capability). We have used the control panel -
> system - hardware - disk drives - properties - and unchecked the "Enable
> write caching on the disk" setting. However, files are being written as if
> the disk cache is still enabled. We have seen the disk writes take up to 14
> seconds on FAT32 file system and about 3 seconds to actually get written to
> disk. We have also tried to use the DISKCACHE.EXE tool with the same results.
>
> Is the disabling of disk cache setting not working with XP Embedded? Is
> there a workaround that can be used to enforce this or could there be a
> component missing that is needed to make this work?
>
> Thanks!

 

Hi Slobodan,

"Optimize for quick removal" is disabled for this drive (it is not a
removable drive).

How can we force this in the registry?

Thanks,
Bruce

"Slobodan Brcin (eMVP)" wrote:

> Hi Bruce,
>
> You will have to switch to "optimize for quick removal". (If you can't then you will have to force it in registry)
>
> Regards,
> Slobodan
>
> "BruceKrautbauer" <> wrote in message news:...
> > Our system is running XP Embedded with Service Pack 1. We have attempted to
> > disable the hard disk write cache to help reduce corrupt disk writes in the
> > event the user powers off the system (we have no control on power off and do
> > not have any battery backup capability). We have used the control panel -
> > system - hardware - disk drives - properties - and unchecked the "Enable
> > write caching on the disk" setting. However, files are being written as if
> > the disk cache is still enabled. We have seen the disk writes take up to 14
> > seconds on FAT32 file system and about 3 seconds to actually get written to
> > disk. We have also tried to use the DISKCACHE.EXE tool with the same results.
> >
> > Is the disabling of disk cache setting not working with XP Embedded? Is
> > there a workaround that can be used to enforce this or could there be a
> > component missing that is needed to make this work?
> >
> > Thanks!
>
>
>

 

Hi Bruce,

The easiest (hack) way would be to modify disk.inf.
But for test purposes find in registry values under Device Parameters\Classpnp\UserRemovalPolicy set it to dword 3.

This will be somewhere like:
HKLM\System\CurrentControlSet\Enum\.....\Device Parameters\Classpnp\UserRemovalPolicy

Use regmon to find exact position.

Regards,
Slobodan

"BruceKrautbauer" <> wrote in message news:...
> Hi Slobodan,
>
> "Optimize for quick removal" is disabled for this drive (it is not a
> removable drive).
>
> How can we force this in the registry?
>
> Thanks,
> Bruce
>
> "Slobodan Brcin (eMVP)" wrote:
>
> > Hi Bruce,
> >
> > You will have to switch to "optimize for quick removal". (If you can't then you will have to force it in registry)
> >
> > Regards,
> > Slobodan
> >
> > "BruceKrautbauer" <> wrote in message news:...
> > > Our system is running XP Embedded with Service Pack 1. We have attempted to
> > > disable the hard disk write cache to help reduce corrupt disk writes in the
> > > event the user powers off the system (we have no control on power off and do
> > > not have any battery backup capability). We have used the control panel -
> > > system - hardware - disk drives - properties - and unchecked the "Enable
> > > write caching on the disk" setting. However, files are being written as if
> > > the disk cache is still enabled. We have seen the disk writes take up to 14
> > > seconds on FAT32 file system and about 3 seconds to actually get written to
> > > disk. We have also tried to use the DISKCACHE.EXE tool with the same results.
> > >
> > > Is the disabling of disk cache setting not working with XP Embedded? Is
> > > there a workaround that can be used to enforce this or could there be a
> > > component missing that is needed to make this work?
> > >
> > > Thanks!
> >
> >
> >

 

Hi Slobodan,

I also have problems with write caching and tried your registry patch,
but without success.
Can you give me some details about the "hack" solution? (modify
disk.inf)

Thanks,
Bernhard

 

Hi Bernhard,

If you can't make it work trough registry then inf file will not do you any good :-(
I assume that you used regedit for finding and setting value in registry, right?
Have you restarted computer after the change?
Also make sure that value remained unchanged.

Regards,
Slobodan

<> wrote in message news:...
> Hi Slobodan,
>
> I also have problems with write caching and tried your registry patch,
> but without success.
> Can you give me some details about the "hack" solution? (modify
> disk.inf)
>
> Thanks,
> Bernhard
>

 

Hi Slobodan,

yes, I used regedit, restarted the computer, and the value remained
unchanged.
Here is how the regedit export looks like:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
Parameters\Classpnp]
"UserRemovalPolicy"=dword:00000003

When I test with a USB stick with activated "optimize for quick
removal"
switch, there are no problems with sudden power off.
But for the compact flash card (and here I need this feature!),
tests show that files get corrupted, even with the above registry
setting.

I wrote a small tool to flush buffers (uses FlushFileBuffers),
and this works, but it would be much better to have a mode where
flushing is done automatically, even at the cost of performance
decrease.
(Obviously this mode exists, as the experience with the USB stick
shows...)

Regards,
Bernhard

Slobodan Brcin (eMVP) wrote:
> Hi Bernhard,
>
> If you can't make it work trough registry then inf file will not do
you any good :-(
> I assume that you used regedit for finding and setting value in
registry, right?
> Have you restarted computer after the change?
> Also make sure that value remained unchanged.
>
> Regards,
> Slobodan
>
> <> wrote in message
news:...
> > Hi Slobodan,
> >
> > I also have problems with write caching and tried your registry
patch,
> > but without success.
> > Can you give me some details about the "hack" solution? (modify
> > disk.inf)
> >
> > Thanks,
> > Bernhard
> >

 

Hi Bernhard,

Few facts from DDK:
1. RemovalPolicyExpectSurpriseRemoval = 3
2.
#define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
#define CLASSP_REG_WRITE_CACHE_VALUE_NAME (L"WriteCacheEnableOverride")
#define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME (L"UserRemovalPolicy")

3. There is WriteCacheEnableOverride but this is override that is used to enable and not to disable caching in filesystems.
4. UserRemovalPolicy of 3 with override and set flag DeviceHotplug to true.
5. This is from DDK classpnp implementation. Comment in code speak for itself:
//
// this refers to devices which, for reasons not yet understood,
// do not fail PREVENT_MEDIA_REMOVAL requests even though they
// have no way to lock the media into the drive. this allows
// the filesystems to turn off delayed-write caching for these
// devices as well.
//

if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
FDO_HACK_CANNOT_LOCK_MEDIA)) {
fdoData->HotplugInfo.MediaHotplug = TRUE;
} else {
fdoData->HotplugInfo.MediaHotplug = FALSE;
}

6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)



To conclude this try playing with registry value "HackMask" bit 0. Let us know if this helped.

Regards,
Slobodan


<> wrote in message news:...
> Hi Slobodan,
>
> yes, I used regedit, restarted the computer, and the value remained
> unchanged.
> Here is how the regedit export looks like:
>
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> Parameters\Classpnp]
> "UserRemovalPolicy"=dword:00000003
>
> When I test with a USB stick with activated "optimize for quick
> removal"
> switch, there are no problems with sudden power off.
> But for the compact flash card (and here I need this feature!),
> tests show that files get corrupted, even with the above registry
> setting.
>
> I wrote a small tool to flush buffers (uses FlushFileBuffers),
> and this works, but it would be much better to have a mode where
> flushing is done automatically, even at the cost of performance
> decrease.
> (Obviously this mode exists, as the experience with the USB stick
> shows...)
>
> Regards,
> Bernhard
>
> Slobodan Brcin (eMVP) wrote:
> > Hi Bernhard,
> >
> > If you can't make it work trough registry then inf file will not do
> you any good :-(
> > I assume that you used regedit for finding and setting value in
> registry, right?
> > Have you restarted computer after the change?
> > Also make sure that value remained unchanged.
> >
> > Regards,
> > Slobodan
> >
> > <> wrote in message
> news:...
> > > Hi Slobodan,
> > >
> > > I also have problems with write caching and tried your registry
> patch,
> > > but without success.
> > > Can you give me some details about the "hack" solution? (modify
> > > disk.inf)
> > >
> > > Thanks,
> > > Bernhard
> > >
>

 

Hi Slobodan,

- Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
did not help.

- Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
had the effect that I could not enable write caching in the
properties dialog any more (which would be OK), but did not
help either.
(This idea stems from the following DDK source line
#define HackDisableWriteCache (0x08)

- I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
I was able to persistently change the DeviceHotplug value to 1
for the CF device, but this did not help, too.
The MediaRemovable value is still 0 (it is 1 for the USB
stick), and I it seems I just can't let Windows treat the CF
card like a removable hotplug device :-(

Thanks for your help anyway
Bernhard


Slobodan Brcin (eMVP) wrote:
> Hi Bernhard,
>
> Few facts from DDK:
> 1. RemovalPolicyExpectSurpriseRemoval = 3
> 2.
> #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
(L"WriteCacheEnableOverride")
> #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
(L"UserRemovalPolicy")
>
> 3. There is WriteCacheEnableOverride but this is override that is
used to enable and not to disable caching in filesystems.
> 4. UserRemovalPolicy of 3 with override and set flag DeviceHotplug to
true.
> 5. This is from DDK classpnp implementation. Comment in code speak
for itself:
> //
> // this refers to devices which, for reasons not yet understood,
> // do not fail PREVENT_MEDIA_REMOVAL requests even though they
> // have no way to lock the media into the drive. this allows
> // the filesystems to turn off delayed-write caching for these
> // devices as well.
> //
>
> if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> FDO_HACK_CANNOT_LOCK_MEDIA)) {
> fdoData->HotplugInfo.MediaHotplug = TRUE;
> } else {
> fdoData->HotplugInfo.MediaHotplug = FALSE;
> }
>
> 6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
>
>
>
> To conclude this try playing with registry value "HackMask" bit 0.
Let us know if this helped.
>
> Regards,
> Slobodan
>
>
> <> wrote in message
news:...
> > Hi Slobodan,
> >
> > yes, I used regedit, restarted the computer, and the value remained
> > unchanged.
> > Here is how the regedit export looks like:
> >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > Parameters\Classpnp]
> > "UserRemovalPolicy"=dword:00000003
> >
> > When I test with a USB stick with activated "optimize for quick
> > removal"
> > switch, there are no problems with sudden power off.
> > But for the compact flash card (and here I need this feature!),
> > tests show that files get corrupted, even with the above registry
> > setting.
> >
> > I wrote a small tool to flush buffers (uses FlushFileBuffers),
> > and this works, but it would be much better to have a mode where
> > flushing is done automatically, even at the cost of performance
> > decrease.
> > (Obviously this mode exists, as the experience with the USB stick
> > shows...)
> >
> > Regards,
> > Bernhard
> >
> > Slobodan Brcin (eMVP) wrote:
> > > Hi Bernhard,
> > >
> > > If you can't make it work trough registry then inf file will not
do
> > you any good :-(
> > > I assume that you used regedit for finding and setting value in
> > registry, right?
> > > Have you restarted computer after the change?
> > > Also make sure that value remained unchanged.
> > >
> > > Regards,
> > > Slobodan
> > >
> > > <> wrote in message
> > news:...
> > > > Hi Slobodan,
> > > >
> > > > I also have problems with write caching and tried your registry
> > patch,
> > > > but without success.
> > > > Can you give me some details about the "hack" solution? (modify
> > > > disk.inf)
> > > >
> > > > Thanks,
> > > > Bernhard
> > > >
> >

 

Bernhard,

See if this of any help:
http://groups-beta.google.com/group..._frm/thread/1c384aad34673b20#b0feae113d014446

KM

> Hi Slobodan,
>
> - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> did not help.
>
> - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> had the effect that I could not enable write caching in the
> properties dialog any more (which would be OK), but did not
> help either.
> (This idea stems from the following DDK source line
> #define HackDisableWriteCache (0x08)
>
> - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> I was able to persistently change the DeviceHotplug value to 1
> for the CF device, but this did not help, too.
> The MediaRemovable value is still 0 (it is 1 for the USB
> stick), and I it seems I just can't let Windows treat the CF
> card like a removable hotplug device :-(
>
> Thanks for your help anyway
> Bernhard
>
>
> Slobodan Brcin (eMVP) wrote:
>> Hi Bernhard,
>>
>> Few facts from DDK:
>> 1. RemovalPolicyExpectSurpriseRemoval = 3
>> 2.
>> #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
>> #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> (L"WriteCacheEnableOverride")
>> #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> (L"UserRemovalPolicy")
>>
>> 3. There is WriteCacheEnableOverride but this is override that is
> used to enable and not to disable caching in filesystems.
>> 4. UserRemovalPolicy of 3 with override and set flag DeviceHotplug to
> true.
>> 5. This is from DDK classpnp implementation. Comment in code speak
> for itself:
>> //
>> // this refers to devices which, for reasons not yet understood,
>> // do not fail PREVENT_MEDIA_REMOVAL requests even though they
>> // have no way to lock the media into the drive. this allows
>> // the filesystems to turn off delayed-write caching for these
>> // devices as well.
>> //
>>
>> if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
>> FDO_HACK_CANNOT_LOCK_MEDIA)) {
>> fdoData->HotplugInfo.MediaHotplug = TRUE;
>> } else {
>> fdoData->HotplugInfo.MediaHotplug = FALSE;
>> }
>>
>> 6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
>>
>>
>>
>> To conclude this try playing with registry value "HackMask" bit 0.
> Let us know if this helped.
>>
>> Regards,
>> Slobodan
>>
>>
>> <> wrote in message
> news:...
>> > Hi Slobodan,
>> >
>> > yes, I used regedit, restarted the computer, and the value remained
>> > unchanged.
>> > Here is how the regedit export looks like:
>> >
>> >
>>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
>> > Parameters\Classpnp]
>> > "UserRemovalPolicy"=dword:00000003
>> >
>> > When I test with a USB stick with activated "optimize for quick
>> > removal"
>> > switch, there are no problems with sudden power off.
>> > But for the compact flash card (and here I need this feature!),
>> > tests show that files get corrupted, even with the above registry
>> > setting.
>> >
>> > I wrote a small tool to flush buffers (uses FlushFileBuffers),
>> > and this works, but it would be much better to have a mode where
>> > flushing is done automatically, even at the cost of performance
>> > decrease.
>> > (Obviously this mode exists, as the experience with the USB stick
>> > shows...)
>> >
>> > Regards,
>> > Bernhard
>> >
>> > Slobodan Brcin (eMVP) wrote:
>> > > Hi Bernhard,
>> > >
>> > > If you can't make it work trough registry then inf file will not
> do
>> > you any good :-(
>> > > I assume that you used regedit for finding and setting value in
>> > registry, right?
>> > > Have you restarted computer after the change?
>> > > Also make sure that value remained unchanged.
>> > >
>> > > Regards,
>> > > Slobodan
>> > >
>> > > <> wrote in message
>> > news:...
>> > > > Hi Slobodan,
>> > > >
>> > > > I also have problems with write caching and tried your registry
>> > patch,
>> > > > but without success.
>> > > > Can you give me some details about the "hack" solution? (modify
>> > > > disk.inf)
>> > > >
>> > > > Thanks,
>> > > > Bernhard
>> > > >
>> >
>

 

Try:

UserWriteCacheSetting:
http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups

I have no idea where you dig out "SpecialFlags" key but look at the following that only mention value that you use, this is
hardcoded hack for specific disk models.

Following call set entries that you mention:
ClassScanForSpecial(fdoExtension, DiskBadControllers, DiskSetSpecialHacks);


And as you can see DiskBadControllers is hardcoded.

CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
{ "COMPAQ" , "PD-1" , NULL, 0x02 },
{ "CONNER" , "CP3500" , NULL, 0x02 },
{ "FUJITSU" , "M2652S-512" , NULL, 0x01 },
{ "HP ", "C1113F " , NULL, 0x20 },
// iomegas require START_UNIT commands so be sure to match all of them.
{ "iomega" , "jaz" , NULL, 0x30 },
{ "iomega" , NULL , NULL, 0x20 },
{ "IOMEGA" , "ZIP" , NULL, 0x27 },
{ "IOMEGA" , NULL , NULL, 0x20 },
{ "MAXTOR" , "MXT-540SL" , "I1.2", 0x01 },
{ "MICROP" , "1936-21MW1002002" , NULL, 0x03 },
{ "OLIVETTI", "CP3500" , NULL, 0x02 },
{ "SEAGATE" , "ST41601N" , "0102", 0x02 },
{ "SEAGATE" , "ST3655N" , NULL, 0x08 },
{ "SEAGATE" , "ST3390N" , NULL, 0x08 },
{ "SEAGATE" , "ST12550N" , NULL, 0x08 },
{ "SEAGATE" , "ST32430N" , NULL, 0x08 },
{ "SEAGATE" , "ST31230N" , NULL, 0x08 },
{ "SEAGATE" , "ST15230N" , NULL, 0x08 },
{ "SyQuest" , "SQ5110" , "CHC", 0x03 },
{ "TOSHIBA" , "MK538FB" , "60", 0x01 },
{ NULL , NULL , NULL, 0x0 }
};

Regards,
Slobodan


// HackDisableWriteCache
// CLASS_SPECIAL_DISABLE_WRITE_CACHE

"Bernhard" <> wrote in message news:...
> Hi Slobodan,
>
> - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> did not help.
>
> - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> had the effect that I could not enable write caching in the
> properties dialog any more (which would be OK), but did not
> help either.
> (This idea stems from the following DDK source line
> #define HackDisableWriteCache (0x08)
>
> - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> I was able to persistently change the DeviceHotplug value to 1
> for the CF device, but this did not help, too.
> The MediaRemovable value is still 0 (it is 1 for the USB
> stick), and I it seems I just can't let Windows treat the CF
> card like a removable hotplug device :-(
>
> Thanks for your help anyway
> Bernhard
>
>
> Slobodan Brcin (eMVP) wrote:
> > Hi Bernhard,
> >
> > Few facts from DDK:
> > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > 2.
> > #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> (L"WriteCacheEnableOverride")
> > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> (L"UserRemovalPolicy")
> >
> > 3. There is WriteCacheEnableOverride but this is override that is
> used to enable and not to disable caching in filesystems.
> > 4. UserRemovalPolicy of 3 with override and set flag DeviceHotplug to
> true.
> > 5. This is from DDK classpnp implementation. Comment in code speak
> for itself:
> > //
> > // this refers to devices which, for reasons not yet understood,
> > // do not fail PREVENT_MEDIA_REMOVAL requests even though they
> > // have no way to lock the media into the drive. this allows
> > // the filesystems to turn off delayed-write caching for these
> > // devices as well.
> > //
> >
> > if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > } else {
> > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > }
> >
> > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
> >
> >
> >
> > To conclude this try playing with registry value "HackMask" bit 0.
> Let us know if this helped.
> >
> > Regards,
> > Slobodan
> >
> >
> > <> wrote in message
> news:...
> > > Hi Slobodan,
> > >
> > > yes, I used regedit, restarted the computer, and the value remained
> > > unchanged.
> > > Here is how the regedit export looks like:
> > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > Parameters\Classpnp]
> > > "UserRemovalPolicy"=dword:00000003
> > >
> > > When I test with a USB stick with activated "optimize for quick
> > > removal"
> > > switch, there are no problems with sudden power off.
> > > But for the compact flash card (and here I need this feature!),
> > > tests show that files get corrupted, even with the above registry
> > > setting.
> > >
> > > I wrote a small tool to flush buffers (uses FlushFileBuffers),
> > > and this works, but it would be much better to have a mode where
> > > flushing is done automatically, even at the cost of performance
> > > decrease.
> > > (Obviously this mode exists, as the experience with the USB stick
> > > shows...)
> > >
> > > Regards,
> > > Bernhard
> > >
> > > Slobodan Brcin (eMVP) wrote:
> > > > Hi Bernhard,
> > > >
> > > > If you can't make it work trough registry then inf file will not
> do
> > > you any good :-(
> > > > I assume that you used regedit for finding and setting value in
> > > registry, right?
> > > > Have you restarted computer after the change?
> > > > Also make sure that value remained unchanged.
> > > >
> > > > Regards,
> > > > Slobodan
> > > >
> > > > <> wrote in message
> > > news:...
> > > > > Hi Slobodan,
> > > > >
> > > > > I also have problems with write caching and tried your registry
> > > patch,
> > > > > but without success.
> > > > > Can you give me some details about the "hack" solution? (modify
> > > > > disk.inf)
> > > > >
> > > > > Thanks,
> > > > > Bernhard
> > > > >
> > >
>

 

Hi Konstantin,

I think I did similar things as was reported in
that posting (using IOCTL_STORAGE_SET_HOTPLUG_INFO to set
the DeviceHotplug flag), but it did not help.
A major difference is that my device is not removable
while the device in that posting is removable.
It would be not surprising (and in fact, coherent)
if the Hotplug info is completely ignored for
non-removable devices.

Regards,
Bernhard

KM wrote:
> Bernhard,
>
> See if this of any help:
>
http://groups-beta.google.com/group..._frm/thread/1c384aad34673b20#b0feae113d014446
>
> KM
>
> > Hi Slobodan,
> >
> > - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> > did not help.
> >
> > - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> > had the effect that I could not enable write caching in the
> > properties dialog any more (which would be OK), but did not
> > help either.
> > (This idea stems from the following DDK source line
> > #define HackDisableWriteCache (0x08)
> >
> > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > I was able to persistently change the DeviceHotplug value to 1
> > for the CF device, but this did not help, too.
> > The MediaRemovable value is still 0 (it is 1 for the USB
> > stick), and I it seems I just can't let Windows treat the CF
> > card like a removable hotplug device :-(
> >
> > Thanks for your help anyway
> > Bernhard
> >
> >
> > Slobodan Brcin (eMVP) wrote:
> >> Hi Bernhard,
> >>
> >> Few facts from DDK:
> >> 1. RemovalPolicyExpectSurpriseRemoval = 3
> >> 2.
> >> #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> >> #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > (L"WriteCacheEnableOverride")
> >> #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > (L"UserRemovalPolicy")
> >>
> >> 3. There is WriteCacheEnableOverride but this is override that is
> > used to enable and not to disable caching in filesystems.
> >> 4. UserRemovalPolicy of 3 with override and set flag DeviceHotplug
to
> > true.
> >> 5. This is from DDK classpnp implementation. Comment in code speak
> > for itself:
> >> //
> >> // this refers to devices which, for reasons not yet
understood,
> >> // do not fail PREVENT_MEDIA_REMOVAL requests even though they
> >> // have no way to lock the media into the drive. this allows
> >> // the filesystems to turn off delayed-write caching for these
> >> // devices as well.
> >> //
> >>
> >> if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> >> FDO_HACK_CANNOT_LOCK_MEDIA)) {
> >> fdoData->HotplugInfo.MediaHotplug = TRUE;
> >> } else {
> >> fdoData->HotplugInfo.MediaHotplug = FALSE;
> >> }
> >>
> >> 6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
> >>
> >>
> >>
> >> To conclude this try playing with registry value "HackMask" bit 0.
> > Let us know if this helped.
> >>
> >> Regards,
> >> Slobodan
> >>
> >>
> >> <> wrote in message
> > news:...
> >> > Hi Slobodan,
> >> >
> >> > yes, I used regedit, restarted the computer, and the value
remained
> >> > unchanged.
> >> > Here is how the regedit export looks like:
> >> >
> >> >
> >>
> >
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> >> > Parameters\Classpnp]
> >> > "UserRemovalPolicy"=dword:00000003
> >> >
> >> > When I test with a USB stick with activated "optimize for quick
> >> > removal"
> >> > switch, there are no problems with sudden power off.
> >> > But for the compact flash card (and here I need this feature!),
> >> > tests show that files get corrupted, even with the above
registry
> >> > setting.
> >> >
> >> > I wrote a small tool to flush buffers (uses FlushFileBuffers),
> >> > and this works, but it would be much better to have a mode where
> >> > flushing is done automatically, even at the cost of performance
> >> > decrease.
> >> > (Obviously this mode exists, as the experience with the USB
stick
> >> > shows...)
> >> >
> >> > Regards,
> >> > Bernhard
> >> >
> >> > Slobodan Brcin (eMVP) wrote:
> >> > > Hi Bernhard,
> >> > >
> >> > > If you can't make it work trough registry then inf file will
not
> > do
> >> > you any good :-(
> >> > > I assume that you used regedit for finding and setting value
in
> >> > registry, right?
> >> > > Have you restarted computer after the change?
> >> > > Also make sure that value remained unchanged.
> >> > >
> >> > > Regards,
> >> > > Slobodan
> >> > >
> >> > > <> wrote in message
> >> > news:...
> >> > > > Hi Slobodan,
> >> > > >
> >> > > > I also have problems with write caching and tried your
registry
> >> > patch,
> >> > > > but without success.
> >> > > > Can you give me some details about the "hack" solution?
(modify
> >> > > > disk.inf)
> >> > > >
> >> > > > Thanks,
> >> > > > Bernhard
> >> > > >
> >> >
> >

 

Hi Slobodan,

the registry value UserWriteCacheSetting=0x0 is automatically
created when I un-check the "Enable write caching on the disk"
check-box in the properties GUI.
That was of course what I tried first, but it had no effect on
the corrupted file problems after power down.

I don't know much about caching issues, but I conclude from the
explanation for the "Optimize for quick removal" switch in the GUI
("This setting disables write caching on the disk and in Windows, ...")
that there are two levels of write caching: hardware level and Windows
level. The UserWriteCacheSetting value seems to have effect only on
hardware level caching. (But this is actually only speculation...)

At the moment I think I have to fall back on a tool that calls
FlushFileBuffers every 5 seconds or so - not very satisfactory,
but I hope this will reduce the errors considerably.

Regards,
Bernhard


Slobodan Brcin (eMVP) wrote:
> Try:
>
> UserWriteCacheSetting:
>
http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
>
> I have no idea where you dig out "SpecialFlags" key but look at the
following that only mention value that you use, this is
> hardcoded hack for specific disk models.
>
> Following call set entries that you mention:
> ClassScanForSpecial(fdoExtension, DiskBadControllers,
DiskSetSpecialHacks);
>
>
> And as you can see DiskBadControllers is hardcoded.
>
> CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
> { "COMPAQ" , "PD-1" , NULL, 0x02 },
> { "CONNER" , "CP3500" , NULL, 0x02 },
> { "FUJITSU" , "M2652S-512" , NULL, 0x01 },
> { "HP ", "C1113F " , NULL, 0x20 },
> // iomegas require START_UNIT commands so be sure to match all of
them.
> { "iomega" , "jaz" , NULL, 0x30 },
> { "iomega" , NULL , NULL, 0x20 },
> { "IOMEGA" , "ZIP" , NULL, 0x27 },
> { "IOMEGA" , NULL , NULL, 0x20 },
> { "MAXTOR" , "MXT-540SL" , "I1.2", 0x01 },
> { "MICROP" , "1936-21MW1002002" , NULL, 0x03 },
> { "OLIVETTI", "CP3500" , NULL, 0x02 },
> { "SEAGATE" , "ST41601N" , "0102", 0x02 },
> { "SEAGATE" , "ST3655N" , NULL, 0x08 },
> { "SEAGATE" , "ST3390N" , NULL, 0x08 },
> { "SEAGATE" , "ST12550N" , NULL, 0x08 },
> { "SEAGATE" , "ST32430N" , NULL, 0x08 },
> { "SEAGATE" , "ST31230N" , NULL, 0x08 },
> { "SEAGATE" , "ST15230N" , NULL, 0x08 },
> { "SyQuest" , "SQ5110" , "CHC", 0x03 },
> { "TOSHIBA" , "MK538FB" , "60", 0x01 },
> { NULL , NULL , NULL, 0x0 }
> };
>
> Regards,
> Slobodan
>
>
> // HackDisableWriteCache
> // CLASS_SPECIAL_DISABLE_WRITE_CACHE
>
> "Bernhard" <> wrote in message
news:...
> > Hi Slobodan,
> >
> > - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> > did not help.
> >
> > - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> > had the effect that I could not enable write caching in the
> > properties dialog any more (which would be OK), but did not
> > help either.
> > (This idea stems from the following DDK source line
> > #define HackDisableWriteCache (0x08)
> >
> > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > I was able to persistently change the DeviceHotplug value to 1
> > for the CF device, but this did not help, too.
> > The MediaRemovable value is still 0 (it is 1 for the USB
> > stick), and I it seems I just can't let Windows treat the CF
> > card like a removable hotplug device :-(
> >
> > Thanks for your help anyway
> > Bernhard
> >
> >
> > Slobodan Brcin (eMVP) wrote:
> > > Hi Bernhard,
> > >
> > > Few facts from DDK:
> > > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > > 2.
> > > #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> > > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > (L"WriteCacheEnableOverride")
> > > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > (L"UserRemovalPolicy")
> > >
> > > 3. There is WriteCacheEnableOverride but this is override that is
> > used to enable and not to disable caching in filesystems.
> > > 4. UserRemovalPolicy of 3 with override and set flag
DeviceHotplug to
> > true.
> > > 5. This is from DDK classpnp implementation. Comment in code
speak
> > for itself:
> > > //
> > > // this refers to devices which, for reasons not yet
understood,
> > > // do not fail PREVENT_MEDIA_REMOVAL requests even though
they
> > > // have no way to lock the media into the drive. this allows
> > > // the filesystems to turn off delayed-write caching for
these
> > > // devices as well.
> > > //
> > >
> > > if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > > } else {
> > > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > > }
> > >
> > > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
> > >
> > >
> > >
> > > To conclude this try playing with registry value "HackMask" bit
0.
> > Let us know if this helped.
> > >
> > > Regards,
> > > Slobodan
> > >
> > >
> > > <> wrote in message
> > news:...
> > > > Hi Slobodan,
> > > >
> > > > yes, I used regedit, restarted the computer, and the value
remained
> > > > unchanged.
> > > > Here is how the regedit export looks like:
> > > >
> > > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > > Parameters\Classpnp]
> > > > "UserRemovalPolicy"=dword:00000003
> > > >
> > > > When I test with a USB stick with activated "optimize for quick
> > > > removal"
> > > > switch, there are no problems with sudden power off.
> > > > But for the compact flash card (and here I need this feature!),
> > > > tests show that files get corrupted, even with the above
registry
> > > > setting.
> > > >
> > > > I wrote a small tool to flush buffers (uses FlushFileBuffers),
> > > > and this works, but it would be much better to have a mode
where
> > > > flushing is done automatically, even at the cost of performance
> > > > decrease.
> > > > (Obviously this mode exists, as the experience with the USB
stick
> > > > shows...)
> > > >
> > > > Regards,
> > > > Bernhard
> > > >
> > > > Slobodan Brcin (eMVP) wrote:
> > > > > Hi Bernhard,
> > > > >
> > > > > If you can't make it work trough registry then inf file will
not
> > do
> > > > you any good :-(
> > > > > I assume that you used regedit for finding and setting value
in
> > > > registry, right?
> > > > > Have you restarted computer after the change?
> > > > > Also make sure that value remained unchanged.
> > > > >
> > > > > Regards,
> > > > > Slobodan
> > > > >
> > > > > <> wrote in message
> > > > news:...
> > > > > > Hi Slobodan,
> > > > > >
> > > > > > I also have problems with write caching and tried your
registry
> > > > patch,
> > > > > > but without success.
> > > > > > Can you give me some details about the "hack" solution?
(modify
> > > > > > disk.inf)
> > > > > >
> > > > > > Thanks,
> > > > > > Bernhard
> > > > > >
> > > >
> >

 

Hi Bernhard,

First do you use NTFS or FAT?
I think that NTFS was not created to work on removable disks so it might not flush data on its own. FAT actually flushed data on
removable disks.

Now when you mention this, I remembered that there was a discussion on this subject although I can't find the right thread :-(
Anyhow you can't do anything to disk internal caching trough MS registry switches, but rather trough sending proprietary SCSI codes
to disk device to disable caching or to alter internal caching behavior.

If you get corruption when you press reset button then this is windows software issue.
If you get corruption when you cut power then this might be internal disk caching problem.

Optimize for quick removal will try to pass all write request to disk controller as they come, with minimum or no delay. Also it
should have different behavior with regards on dirty bit.

http://groups-beta.google.com/group..._frm/thread/0a00a67f882086c7#4ee475b3e0c63a48
http://groups-beta.google.com/group..._frm/thread/a692df61fb93fb8d#4a434eecc6c89102


Regards,
Slobodan


"Bernhard" <> wrote in message news:...
> Hi Slobodan,
>
> the registry value UserWriteCacheSetting=0x0 is automatically
> created when I un-check the "Enable write caching on the disk"
> check-box in the properties GUI.
> That was of course what I tried first, but it had no effect on
> the corrupted file problems after power down.
>
> I don't know much about caching issues, but I conclude from the
> explanation for the "Optimize for quick removal" switch in the GUI
> ("This setting disables write caching on the disk and in Windows, ...")
> that there are two levels of write caching: hardware level and Windows
> level. The UserWriteCacheSetting value seems to have effect only on
> hardware level caching. (But this is actually only speculation...)
>
> At the moment I think I have to fall back on a tool that calls
> FlushFileBuffers every 5 seconds or so - not very satisfactory,
> but I hope this will reduce the errors considerably.
>
> Regards,
> Bernhard
>
>
> Slobodan Brcin (eMVP) wrote:
> > Try:
> >
> > UserWriteCacheSetting:
> >
> http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
> >
> > I have no idea where you dig out "SpecialFlags" key but look at the
> following that only mention value that you use, this is
> > hardcoded hack for specific disk models.
> >
> > Following call set entries that you mention:
> > ClassScanForSpecial(fdoExtension, DiskBadControllers,
> DiskSetSpecialHacks);
> >
> >
> > And as you can see DiskBadControllers is hardcoded.
> >
> > CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
> > { "COMPAQ" , "PD-1" , NULL, 0x02 },
> > { "CONNER" , "CP3500" , NULL, 0x02 },
> > { "FUJITSU" , "M2652S-512" , NULL, 0x01 },
> > { "HP ", "C1113F " , NULL, 0x20 },
> > // iomegas require START_UNIT commands so be sure to match all of
> them.
> > { "iomega" , "jaz" , NULL, 0x30 },
> > { "iomega" , NULL , NULL, 0x20 },
> > { "IOMEGA" , "ZIP" , NULL, 0x27 },
> > { "IOMEGA" , NULL , NULL, 0x20 },
> > { "MAXTOR" , "MXT-540SL" , "I1.2", 0x01 },
> > { "MICROP" , "1936-21MW1002002" , NULL, 0x03 },
> > { "OLIVETTI", "CP3500" , NULL, 0x02 },
> > { "SEAGATE" , "ST41601N" , "0102", 0x02 },
> > { "SEAGATE" , "ST3655N" , NULL, 0x08 },
> > { "SEAGATE" , "ST3390N" , NULL, 0x08 },
> > { "SEAGATE" , "ST12550N" , NULL, 0x08 },
> > { "SEAGATE" , "ST32430N" , NULL, 0x08 },
> > { "SEAGATE" , "ST31230N" , NULL, 0x08 },
> > { "SEAGATE" , "ST15230N" , NULL, 0x08 },
> > { "SyQuest" , "SQ5110" , "CHC", 0x03 },
> > { "TOSHIBA" , "MK538FB" , "60", 0x01 },
> > { NULL , NULL , NULL, 0x0 }
> > };
> >
> > Regards,
> > Slobodan
> >
> >
> > // HackDisableWriteCache
> > // CLASS_SPECIAL_DISABLE_WRITE_CACHE
> >
> > "Bernhard" <> wrote in message
> news:...
> > > Hi Slobodan,
> > >
> > > - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> > > did not help.
> > >
> > > - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> > > had the effect that I could not enable write caching in the
> > > properties dialog any more (which would be OK), but did not
> > > help either.
> > > (This idea stems from the following DDK source line
> > > #define HackDisableWriteCache (0x08)
> > >
> > > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > > I was able to persistently change the DeviceHotplug value to 1
> > > for the CF device, but this did not help, too.
> > > The MediaRemovable value is still 0 (it is 1 for the USB
> > > stick), and I it seems I just can't let Windows treat the CF
> > > card like a removable hotplug device :-(
> > >
> > > Thanks for your help anyway
> > > Bernhard
> > >
> > >
> > > Slobodan Brcin (eMVP) wrote:
> > > > Hi Bernhard,
> > > >
> > > > Few facts from DDK:
> > > > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > > > 2.
> > > > #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> > > > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > > (L"WriteCacheEnableOverride")
> > > > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > > (L"UserRemovalPolicy")
> > > >
> > > > 3. There is WriteCacheEnableOverride but this is override that is
> > > used to enable and not to disable caching in filesystems.
> > > > 4. UserRemovalPolicy of 3 with override and set flag
> DeviceHotplug to
> > > true.
> > > > 5. This is from DDK classpnp implementation. Comment in code
> speak
> > > for itself:
> > > > //
> > > > // this refers to devices which, for reasons not yet
> understood,
> > > > // do not fail PREVENT_MEDIA_REMOVAL requests even though
> they
> > > > // have no way to lock the media into the drive. this allows
> > > > // the filesystems to turn off delayed-write caching for
> these
> > > > // devices as well.
> > > > //
> > > >
> > > > if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > > > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > > > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > > > } else {
> > > > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > > > }
> > > >
> > > > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA (0x00000001)
> > > >
> > > >
> > > >
> > > > To conclude this try playing with registry value "HackMask" bit
> 0.
> > > Let us know if this helped.
> > > >
> > > > Regards,
> > > > Slobodan
> > > >
> > > >
> > > > <> wrote in message
> > > news:...
> > > > > Hi Slobodan,
> > > > >
> > > > > yes, I used regedit, restarted the computer, and the value
> remained
> > > > > unchanged.
> > > > > Here is how the regedit export looks like:
> > > > >
> > > > >
> > > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > > > Parameters\Classpnp]
> > > > > "UserRemovalPolicy"=dword:00000003
> > > > >
> > > > > When I test with a USB stick with activated "optimize for quick
> > > > > removal"
> > > > > switch, there are no problems with sudden power off.
> > > > > But for the compact flash card (and here I need this feature!),
> > > > > tests show that files get corrupted, even with the above
> registry
> > > > > setting.
> > > > >
> > > > > I wrote a small tool to flush buffers (uses FlushFileBuffers),
> > > > > and this works, but it would be much better to have a mode
> where
> > > > > flushing is done automatically, even at the cost of performance
> > > > > decrease.
> > > > > (Obviously this mode exists, as the experience with the USB
> stick
> > > > > shows...)
> > > > >
> > > > > Regards,
> > > > > Bernhard
> > > > >
> > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > Hi Bernhard,
> > > > > >
> > > > > > If you can't make it work trough registry then inf file will
> not
> > > do
> > > > > you any good :-(
> > > > > > I assume that you used regedit for finding and setting value
> in
> > > > > registry, right?
> > > > > > Have you restarted computer after the change?
> > > > > > Also make sure that value remained unchanged.
> > > > > >
> > > > > > Regards,
> > > > > > Slobodan
> > > > > >
> > > > > > <> wrote in message
> > > > > news:...
> > > > > > > Hi Slobodan,
> > > > > > >
> > > > > > > I also have problems with write caching and tried your
> registry
> > > > > patch,
> > > > > > > but without success.
> > > > > > > Can you give me some details about the "hack" solution?
> (modify
> > > > > > > disk.inf)
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Bernhard
> > > > > > >
> > > > >
> > >
>

 

Hi Slobodan,

I did all previous tests with NTFS with compression.

Now I prepared a CF disk with FAT and tested again
(The test is: recursively copy a directory tree
from network drive to disk, then (optionally) do
FlushFileBuffers, then cut power off, reboot, compare
files on disk to files on network. Autochk is enabled.)
With FAT things are even worse:
Without FlushFileBuffers, chkdsk complains about lost
clusters and creates some *.chk files, but the original
files are completely missing.
With FlushFileBuffers, everything is OK.

With NTFS, and without FlushFileBuffers, the situation
is as follows:
chkdsk detects no errors, all files look OK at first glance,
(file length, modification time etc. are OK),
but usually one file (not always the same!) consists of
binary zeros from some offset on. That means that the
NTFS "metadata" is OK, but the user data (file contents)
is corrupted...

So it seems that our only rescue is FlushFileBuffers!
The problem is not with our own application which we
can modify easily, it's with 3rd party SW (e.g. FTP
server, ZIP file extractor, ...) where it would be best
if flushing occurs at least if a file is closed.

Regards,
Bernhard

Slobodan Brcin (eMVP) wrote:
> Hi Bernhard,
>
> First do you use NTFS or FAT?
> I think that NTFS was not created to work on removable disks so it
might not flush data on its own. FAT actually flushed data on
> removable disks.
>
> Now when you mention this, I remembered that there was a discussion
on this subject although I can't find the right thread :-(
> Anyhow you can't do anything to disk internal caching trough MS
registry switches, but rather trough sending proprietary SCSI codes
> to disk device to disable caching or to alter internal caching
behavior.
>
> If you get corruption when you press reset button then this is
windows software issue.
> If you get corruption when you cut power then this might be internal
disk caching problem.
>
> Optimize for quick removal will try to pass all write request to disk
controller as they come, with minimum or no delay. Also it
> should have different behavior with regards on dirty bit.
>
>
http://groups-beta.google.com/group..._frm/thread/0a00a67f882086c7#4ee475b3e0c63a48
>
http://groups-beta.google.com/group..._frm/thread/a692df61fb93fb8d#4a434eecc6c89102
>
>
> Regards,
> Slobodan
>
>
> "Bernhard" <> wrote in message
news:...
> > Hi Slobodan,
> >
> > the registry value UserWriteCacheSetting=0x0 is automatically
> > created when I un-check the "Enable write caching on the disk"
> > check-box in the properties GUI.
> > That was of course what I tried first, but it had no effect on
> > the corrupted file problems after power down.
> >
> > I don't know much about caching issues, but I conclude from the
> > explanation for the "Optimize for quick removal" switch in the GUI
> > ("This setting disables write caching on the disk and in Windows,
....")
> > that there are two levels of write caching: hardware level and
Windows
> > level. The UserWriteCacheSetting value seems to have effect only on
> > hardware level caching. (But this is actually only speculation...)
> >
> > At the moment I think I have to fall back on a tool that calls
> > FlushFileBuffers every 5 seconds or so - not very satisfactory,
> > but I hope this will reduce the errors considerably.
> >
> > Regards,
> > Bernhard
> >
> >
> > Slobodan Brcin (eMVP) wrote:
> > > Try:
> > >
> > > UserWriteCacheSetting:
> > >
> >
http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
> > >
> > > I have no idea where you dig out "SpecialFlags" key but look at
the
> > following that only mention value that you use, this is
> > > hardcoded hack for specific disk models.
> > >
> > > Following call set entries that you mention:
> > > ClassScanForSpecial(fdoExtension, DiskBadControllers,
> > DiskSetSpecialHacks);
> > >
> > >
> > > And as you can see DiskBadControllers is hardcoded.
> > >
> > > CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
> > > { "COMPAQ" , "PD-1" , NULL, 0x02
},
> > > { "CONNER" , "CP3500" , NULL, 0x02
},
> > > { "FUJITSU" , "M2652S-512" , NULL, 0x01
},
> > > { "HP ", "C1113F " , NULL, 0x20
},
> > > // iomegas require START_UNIT commands so be sure to match
all of
> > them.
> > > { "iomega" , "jaz" , NULL, 0x30
},
> > > { "iomega" , NULL , NULL, 0x20
},
> > > { "IOMEGA" , "ZIP" , NULL, 0x27
},
> > > { "IOMEGA" , NULL , NULL, 0x20
},
> > > { "MAXTOR" , "MXT-540SL" , "I1.2", 0x01
},
> > > { "MICROP" , "1936-21MW1002002" , NULL, 0x03
},
> > > { "OLIVETTI", "CP3500" , NULL, 0x02
},
> > > { "SEAGATE" , "ST41601N" , "0102", 0x02
},
> > > { "SEAGATE" , "ST3655N" , NULL, 0x08
},
> > > { "SEAGATE" , "ST3390N" , NULL, 0x08
},
> > > { "SEAGATE" , "ST12550N" , NULL, 0x08
},
> > > { "SEAGATE" , "ST32430N" , NULL, 0x08
},
> > > { "SEAGATE" , "ST31230N" , NULL, 0x08
},
> > > { "SEAGATE" , "ST15230N" , NULL, 0x08
},
> > > { "SyQuest" , "SQ5110" , "CHC", 0x03
},
> > > { "TOSHIBA" , "MK538FB" , "60", 0x01
},
> > > { NULL , NULL , NULL, 0x0
}
> > > };
> > >
> > > Regards,
> > > Slobodan
> > >
> > >
> > > // HackDisableWriteCache
> > > // CLASS_SPECIAL_DISABLE_WRITE_CACHE
> > >
> > > "Bernhard" <> wrote in message
> > news:...
> > > > Hi Slobodan,
> > > >
> > > > - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> > > > did not help.
> > > >
> > > > - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> > > > had the effect that I could not enable write caching in the
> > > > properties dialog any more (which would be OK), but did not
> > > > help either.
> > > > (This idea stems from the following DDK source line
> > > > #define HackDisableWriteCache (0x08)
> > > >
> > > > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > > > I was able to persistently change the DeviceHotplug value to 1
> > > > for the CF device, but this did not help, too.
> > > > The MediaRemovable value is still 0 (it is 1 for the USB
> > > > stick), and I it seems I just can't let Windows treat the CF
> > > > card like a removable hotplug device :-(
> > > >
> > > > Thanks for your help anyway
> > > > Bernhard
> > > >
> > > >
> > > > Slobodan Brcin (eMVP) wrote:
> > > > > Hi Bernhard,
> > > > >
> > > > > Few facts from DDK:
> > > > > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > > > > 2.
> > > > > #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> > > > > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > > > (L"WriteCacheEnableOverride")
> > > > > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > > > (L"UserRemovalPolicy")
> > > > >
> > > > > 3. There is WriteCacheEnableOverride but this is override
that is
> > > > used to enable and not to disable caching in filesystems.
> > > > > 4. UserRemovalPolicy of 3 with override and set flag
> > DeviceHotplug to
> > > > true.
> > > > > 5. This is from DDK classpnp implementation. Comment in code
> > speak
> > > > for itself:
> > > > > //
> > > > > // this refers to devices which, for reasons not yet
> > understood,
> > > > > // do not fail PREVENT_MEDIA_REMOVAL requests even though
> > they
> > > > > // have no way to lock the media into the drive. this
allows
> > > > > // the filesystems to turn off delayed-write caching for
> > these
> > > > > // devices as well.
> > > > > //
> > > > >
> > > > > if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > > > > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > > > > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > > > > } else {
> > > > > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > > > > }
> > > > >
> > > > > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA
(0x00000001)
> > > > >
> > > > >
> > > > >
> > > > > To conclude this try playing with registry value "HackMask"
bit
> > 0.
> > > > Let us know if this helped.
> > > > >
> > > > > Regards,
> > > > > Slobodan
> > > > >
> > > > >
> > > > > <> wrote in message
> > > > news:...
> > > > > > Hi Slobodan,
> > > > > >
> > > > > > yes, I used regedit, restarted the computer, and the value
> > remained
> > > > > > unchanged.
> > > > > > Here is how the regedit export looks like:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > > > > Parameters\Classpnp]
> > > > > > "UserRemovalPolicy"=dword:00000003
> > > > > >
> > > > > > When I test with a USB stick with activated "optimize for
quick
> > > > > > removal"
> > > > > > switch, there are no problems with sudden power off.
> > > > > > But for the compact flash card (and here I need this
feature!),
> > > > > > tests show that files get corrupted, even with the above
> > registry
> > > > > > setting.
> > > > > >
> > > > > > I wrote a small tool to flush buffers (uses
FlushFileBuffers),
> > > > > > and this works, but it would be much better to have a mode
> > where
> > > > > > flushing is done automatically, even at the cost of
performance
> > > > > > decrease.
> > > > > > (Obviously this mode exists, as the experience with the USB
> > stick
> > > > > > shows...)
> > > > > >
> > > > > > Regards,
> > > > > > Bernhard
> > > > > >
> > > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > > Hi Bernhard,
> > > > > > >
> > > > > > > If you can't make it work trough registry then inf file
will
> > not
> > > > do
> > > > > > you any good :-(
> > > > > > > I assume that you used regedit for finding and setting
value
> > in
> > > > > > registry, right?
> > > > > > > Have you restarted computer after the change?
> > > > > > > Also make sure that value remained unchanged.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Slobodan
> > > > > > >
> > > > > > > <> wrote in message
> > > > > >
news:...
> > > > > > > > Hi Slobodan,
> > > > > > > >
> > > > > > > > I also have problems with write caching and tried your
> > registry
> > > > > > patch,
> > > > > > > > but without success.
> > > > > > > > Can you give me some details about the "hack" solution?
> > (modify
> > > > > > > > disk.inf)
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Bernhard
> > > > > > > >
> > > > > >
> > > >
> >

 

Bernhard,

Here is an idea for you that you might have already tried but still worth to mention...

With W2K SP3 MS introduced the "Power Protected" Write Cache Option in additon to the "Write Caching" option.
Basically, to have the FS driver to issue Flush/Write-Through commands you will need to set "Write Caching" option to Enabled and
the "Power Protected" option to Disabled (see more info here: http://support.microsoft.com/?kbid=332023).

Instead of messing up with API for the moment you can try the easiest way - use RK utility diskcache (some info here
http://support.microsoft.com/kb/811392/EN-US)

If it helps, let us know.

--
Regards,
KM, BSquare Corp.


> Hi Slobodan,
>
> I did all previous tests with NTFS with compression.
>
> Now I prepared a CF disk with FAT and tested again
> (The test is: recursively copy a directory tree
> from network drive to disk, then (optionally) do
> FlushFileBuffers, then cut power off, reboot, compare
> files on disk to files on network. Autochk is enabled.)
> With FAT things are even worse:
> Without FlushFileBuffers, chkdsk complains about lost
> clusters and creates some *.chk files, but the original
> files are completely missing.
> With FlushFileBuffers, everything is OK.
>
> With NTFS, and without FlushFileBuffers, the situation
> is as follows:
> chkdsk detects no errors, all files look OK at first glance,
> (file length, modification time etc. are OK),
> but usually one file (not always the same!) consists of
> binary zeros from some offset on. That means that the
> NTFS "metadata" is OK, but the user data (file contents)
> is corrupted...
>
> So it seems that our only rescue is FlushFileBuffers!
> The problem is not with our own application which we
> can modify easily, it's with 3rd party SW (e.g. FTP
> server, ZIP file extractor, ...) where it would be best
> if flushing occurs at least if a file is closed.
>
> Regards,
> Bernhard
>
> Slobodan Brcin (eMVP) wrote:
> > Hi Bernhard,
> >
> > First do you use NTFS or FAT?
> > I think that NTFS was not created to work on removable disks so it
> might not flush data on its own. FAT actually flushed data on
> > removable disks.
> >
> > Now when you mention this, I remembered that there was a discussion
> on this subject although I can't find the right thread :-(
> > Anyhow you can't do anything to disk internal caching trough MS
> registry switches, but rather trough sending proprietary SCSI codes
> > to disk device to disable caching or to alter internal caching
> behavior.
> >
> > If you get corruption when you press reset button then this is
> windows software issue.
> > If you get corruption when you cut power then this might be internal
> disk caching problem.
> >
> > Optimize for quick removal will try to pass all write request to disk
> controller as they come, with minimum or no delay. Also it
> > should have different behavior with regards on dirty bit.
> >
> >
> http://groups-beta.google.com/group..._frm/thread/0a00a67f882086c7#4ee475b3e0c63a48
> >
> http://groups-beta.google.com/group..._frm/thread/a692df61fb93fb8d#4a434eecc6c89102
> >
> >
> > Regards,
> > Slobodan
> >
> >
> > "Bernhard" <> wrote in message
> news:...
> > > Hi Slobodan,
> > >
> > > the registry value UserWriteCacheSetting=0x0 is automatically
> > > created when I un-check the "Enable write caching on the disk"
> > > check-box in the properties GUI.
> > > That was of course what I tried first, but it had no effect on
> > > the corrupted file problems after power down.
> > >
> > > I don't know much about caching issues, but I conclude from the
> > > explanation for the "Optimize for quick removal" switch in the GUI
> > > ("This setting disables write caching on the disk and in Windows,
> ...")
> > > that there are two levels of write caching: hardware level and
> Windows
> > > level. The UserWriteCacheSetting value seems to have effect only on
> > > hardware level caching. (But this is actually only speculation...)
> > >
> > > At the moment I think I have to fall back on a tool that calls
> > > FlushFileBuffers every 5 seconds or so - not very satisfactory,
> > > but I hope this will reduce the errors considerably.
> > >
> > > Regards,
> > > Bernhard
> > >
> > >
> > > Slobodan Brcin (eMVP) wrote:
> > > > Try:
> > > >
> > > > UserWriteCacheSetting:
> > > >
> > >
> http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
> > > >
> > > > I have no idea where you dig out "SpecialFlags" key but look at
> the
> > > following that only mention value that you use, this is
> > > > hardcoded hack for specific disk models.
> > > >
> > > > Following call set entries that you mention:
> > > > ClassScanForSpecial(fdoExtension, DiskBadControllers,
> > > DiskSetSpecialHacks);
> > > >
> > > >
> > > > And as you can see DiskBadControllers is hardcoded.
> > > >
> > > > CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
> > > > { "COMPAQ" , "PD-1" , NULL, 0x02
> },
> > > > { "CONNER" , "CP3500" , NULL, 0x02
> },
> > > > { "FUJITSU" , "M2652S-512" , NULL, 0x01
> },
> > > > { "HP ", "C1113F " , NULL, 0x20
> },
> > > > // iomegas require START_UNIT commands so be sure to match
> all of
> > > them.
> > > > { "iomega" , "jaz" , NULL, 0x30
> },
> > > > { "iomega" , NULL , NULL, 0x20
> },
> > > > { "IOMEGA" , "ZIP" , NULL, 0x27
> },
> > > > { "IOMEGA" , NULL , NULL, 0x20
> },
> > > > { "MAXTOR" , "MXT-540SL" , "I1.2", 0x01
> },
> > > > { "MICROP" , "1936-21MW1002002" , NULL, 0x03
> },
> > > > { "OLIVETTI", "CP3500" , NULL, 0x02
> },
> > > > { "SEAGATE" , "ST41601N" , "0102", 0x02
> },
> > > > { "SEAGATE" , "ST3655N" , NULL, 0x08
> },
> > > > { "SEAGATE" , "ST3390N" , NULL, 0x08
> },
> > > > { "SEAGATE" , "ST12550N" , NULL, 0x08
> },
> > > > { "SEAGATE" , "ST32430N" , NULL, 0x08
> },
> > > > { "SEAGATE" , "ST31230N" , NULL, 0x08
> },
> > > > { "SEAGATE" , "ST15230N" , NULL, 0x08
> },
> > > > { "SyQuest" , "SQ5110" , "CHC", 0x03
> },
> > > > { "TOSHIBA" , "MK538FB" , "60", 0x01
> },
> > > > { NULL , NULL , NULL, 0x0
> }
> > > > };
> > > >
> > > > Regards,
> > > > Slobodan
> > > >
> > > >
> > > > // HackDisableWriteCache
> > > > // CLASS_SPECIAL_DISABLE_WRITE_CACHE
> > > >
> > > > "Bernhard" <> wrote in message
> > > news:...
> > > > > Hi Slobodan,
> > > > >
> > > > > - Setting HackMask=1 (in "...\Device Parameters\Classpnp" key)
> > > > > did not help.
> > > > >
> > > > > - Setting SpecialFlags=8 (in "...\Device Parameters\disk" key)
> > > > > had the effect that I could not enable write caching in the
> > > > > properties dialog any more (which would be OK), but did not
> > > > > help either.
> > > > > (This idea stems from the following DDK source line
> > > > > #define HackDisableWriteCache (0x08)
> > > > >
> > > > > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > > > > I was able to persistently change the DeviceHotplug value to 1
> > > > > for the CF device, but this did not help, too.
> > > > > The MediaRemovable value is still 0 (it is 1 for the USB
> > > > > stick), and I it seems I just can't let Windows treat the CF
> > > > > card like a removable hotplug device :-(
> > > > >
> > > > > Thanks for your help anyway
> > > > > Bernhard
> > > > >
> > > > >
> > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > Hi Bernhard,
> > > > > >
> > > > > > Few facts from DDK:
> > > > > > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > > > > > 2.
> > > > > > #define CLASSP_REG_HACK_VALUE_NAME (L"HackMask")
> > > > > > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > > > > (L"WriteCacheEnableOverride")
> > > > > > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > > > > (L"UserRemovalPolicy")
> > > > > >
> > > > > > 3. There is WriteCacheEnableOverride but this is override
> that is
> > > > > used to enable and not to disable caching in filesystems.
> > > > > > 4. UserRemovalPolicy of 3 with override and set flag
> > > DeviceHotplug to
> > > > > true.
> > > > > > 5. This is from DDK classpnp implementation. Comment in code
> > > speak
> > > > > for itself:
> > > > > > //
> > > > > > // this refers to devices which, for reasons not yet
> > > understood,
> > > > > > // do not fail PREVENT_MEDIA_REMOVAL requests even though
> > > they
> > > > > > // have no way to lock the media into the drive. this
> allows
> > > > > > // the filesystems to turn off delayed-write caching for
> > > these
> > > > > > // devices as well.
> > > > > > //
> > > > > >
> > > > > > if (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > > > > > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > > > > > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > > > > > } else {
> > > > > > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > > > > > }
> > > > > >
> > > > > > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA
> (0x00000001)
> > > > > >
> > > > > >
> > > > > >
> > > > > > To conclude this try playing with registry value "HackMask"
> bit
> > > 0.
> > > > > Let us know if this helped.
> > > > > >
> > > > > > Regards,
> > > > > > Slobodan
> > > > > >
> > > > > >
> > > > > > <> wrote in message
> > > > > news:...
> > > > > > > Hi Slobodan,
> > > > > > >
> > > > > > > yes, I used regedit, restarted the computer, and the value
> > > remained
> > > > > > > unchanged.
> > > > > > > Here is how the regedit export looks like:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > > > > > Parameters\Classpnp]
> > > > > > > "UserRemovalPolicy"=dword:00000003
> > > > > > >
> > > > > > > When I test with a USB stick with activated "optimize for
> quick
> > > > > > > removal"
> > > > > > > switch, there are no problems with sudden power off.
> > > > > > > But for the compact flash card (and here I need this
> feature!),
> > > > > > > tests show that files get corrupted, even with the above
> > > registry
> > > > > > > setting.
> > > > > > >
> > > > > > > I wrote a small tool to flush buffers (uses
> FlushFileBuffers),
> > > > > > > and this works, but it would be much better to have a mode
> > > where
> > > > > > > flushing is done automatically, even at the cost of
> performance
> > > > > > > decrease.
> > > > > > > (Obviously this mode exists, as the experience with the USB
> > > stick
> > > > > > > shows...)
> > > > > > >
> > > > > > > Regards,
> > > > > > > Bernhard
> > > > > > >
> > > > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > > > Hi Bernhard,
> > > > > > > >
> > > > > > > > If you can't make it work trough registry then inf file
> will
> > > not
> > > > > do
> > > > > > > you any good :-(
> > > > > > > > I assume that you used regedit for finding and setting
> value
> > > in
> > > > > > > registry, right?
> > > > > > > > Have you restarted computer after the change?
> > > > > > > > Also make sure that value remained unchanged.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Slobodan
> > > > > > > >
> > > > > > > > <> wrote in message
> > > > > > >
> news:...
> > > > > > > > > Hi Slobodan,
> > > > > > > > >
> > > > > > > > > I also have problems with write caching and tried your
> > > registry
> > > > > > > patch,
> > > > > > > > > but without success.
> > > > > > > > > Can you give me some details about the "hack" solution?
> > > (modify
> > > > > > > > > disk.inf)
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Bernhard
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>

 

Konstantin,

I did not yet get the dskcache tool but I will check this, too.
Thank you for the link, it contains the best information that I have
read about this issue so far. And it seems that the FlushFileBuffers
API is indeed the only way to insure proper cache flushing...

And I am somewhat relieved when I read the following:
"Writing to the registry is an example of an operation that results
in the FlushFileBuffers API being called and the SYNCHRONIZE CACHE
command being sent to the disk."
So at least internally in Windows, they seem to know how to do it...

Regards,
Bernhard

KM wrote:
> Bernhard,
>
> Here is an idea for you that you might have already tried but still
worth to mention...
>
> With W2K SP3 MS introduced the "Power Protected" Write Cache Option
in additon to the "Write Caching" option.
> Basically, to have the FS driver to issue Flush/Write-Through
commands you will need to set "Write Caching" option to Enabled and
> the "Power Protected" option to Disabled (see more info here:
http://support.microsoft.com/?kbid=332023).
>
> Instead of messing up with API for the moment you can try the easiest
way - use RK utility diskcache (some info here
> http://support.microsoft.com/kb/811392/EN-US)
>
> If it helps, let us know.
>
> --
> Regards,
> KM, BSquare Corp.
>
>
> > Hi Slobodan,
> >
> > I did all previous tests with NTFS with compression.
> >
> > Now I prepared a CF disk with FAT and tested again
> > (The test is: recursively copy a directory tree
> > from network drive to disk, then (optionally) do
> > FlushFileBuffers, then cut power off, reboot, compare
> > files on disk to files on network. Autochk is enabled.)
> > With FAT things are even worse:
> > Without FlushFileBuffers, chkdsk complains about lost
> > clusters and creates some *.chk files, but the original
> > files are completely missing.
> > With FlushFileBuffers, everything is OK.
> >
> > With NTFS, and without FlushFileBuffers, the situation
> > is as follows:
> > chkdsk detects no errors, all files look OK at first glance,
> > (file length, modification time etc. are OK),
> > but usually one file (not always the same!) consists of
> > binary zeros from some offset on. That means that the
> > NTFS "metadata" is OK, but the user data (file contents)
> > is corrupted...
> >
> > So it seems that our only rescue is FlushFileBuffers!
> > The problem is not with our own application which we
> > can modify easily, it's with 3rd party SW (e.g. FTP
> > server, ZIP file extractor, ...) where it would be best
> > if flushing occurs at least if a file is closed.
> >
> > Regards,
> > Bernhard
> >
> > Slobodan Brcin (eMVP) wrote:
> > > Hi Bernhard,
> > >
> > > First do you use NTFS or FAT?
> > > I think that NTFS was not created to work on removable disks so
it
> > might not flush data on its own. FAT actually flushed data on
> > > removable disks.
> > >
> > > Now when you mention this, I remembered that there was a
discussion
> > on this subject although I can't find the right thread :-(
> > > Anyhow you can't do anything to disk internal caching trough MS
> > registry switches, but rather trough sending proprietary SCSI codes
> > > to disk device to disable caching or to alter internal caching
> > behavior.
> > >
> > > If you get corruption when you press reset button then this is
> > windows software issue.
> > > If you get corruption when you cut power then this might be
internal
> > disk caching problem.
> > >
> > > Optimize for quick removal will try to pass all write request to
disk
> > controller as they come, with minimum or no delay. Also it
> > > should have different behavior with regards on dirty bit.
> > >
> > >
> >
http://groups-beta.google.com/group..._frm/thread/0a00a67f882086c7#4ee475b3e0c63a48
> > >
> >
http://groups-beta.google.com/group..._frm/thread/a692df61fb93fb8d#4a434eecc6c89102
> > >
> > >
> > > Regards,
> > > Slobodan
> > >
> > >
> > > "Bernhard" <> wrote in message
> > news:...
> > > > Hi Slobodan,
> > > >
> > > > the registry value UserWriteCacheSetting=0x0 is automatically
> > > > created when I un-check the "Enable write caching on the disk"
> > > > check-box in the properties GUI.
> > > > That was of course what I tried first, but it had no effect on
> > > > the corrupted file problems after power down.
> > > >
> > > > I don't know much about caching issues, but I conclude from the
> > > > explanation for the "Optimize for quick removal" switch in the
GUI
> > > > ("This setting disables write caching on the disk and in
Windows,
> > ...")
> > > > that there are two levels of write caching: hardware level and
> > Windows
> > > > level. The UserWriteCacheSetting value seems to have effect
only on
> > > > hardware level caching. (But this is actually only
speculation...)
> > > >
> > > > At the moment I think I have to fall back on a tool that calls
> > > > FlushFileBuffers every 5 seconds or so - not very satisfactory,
> > > > but I hope this will reduce the errors considerably.
> > > >
> > > > Regards,
> > > > Bernhard
> > > >
> > > >
> > > > Slobodan Brcin (eMVP) wrote:
> > > > > Try:
> > > > >
> > > > > UserWriteCacheSetting:
> > > > >
> > > >
> >
http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
> > > > >
> > > > > I have no idea where you dig out "SpecialFlags" key but look
at
> > the
> > > > following that only mention value that you use, this is
> > > > > hardcoded hack for specific disk models.
> > > > >
> > > > > Following call set entries that you mention:
> > > > > ClassScanForSpecial(fdoExtension, DiskBadControllers,
> > > > DiskSetSpecialHacks);
> > > > >
> > > > >
> > > > > And as you can see DiskBadControllers is hardcoded.
> > > > >
> > > > > CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
> > > > > { "COMPAQ" , "PD-1" , NULL,
0x02
> > },
> > > > > { "CONNER" , "CP3500" , NULL,
0x02
> > },
> > > > > { "FUJITSU" , "M2652S-512" , NULL,
0x01
> > },
> > > > > { "HP ", "C1113F " , NULL,
0x20
> > },
> > > > > // iomegas require START_UNIT commands so be sure to
match
> > all of
> > > > them.
> > > > > { "iomega" , "jaz" , NULL,
0x30
> > },
> > > > > { "iomega" , NULL , NULL,
0x20
> > },
> > > > > { "IOMEGA" , "ZIP" , NULL,
0x27
> > },
> > > > > { "IOMEGA" , NULL , NULL,
0x20
> > },
> > > > > { "MAXTOR" , "MXT-540SL" , "I1.2",
0x01
> > },
> > > > > { "MICROP" , "1936-21MW1002002" , NULL,
0x03
> > },
> > > > > { "OLIVETTI", "CP3500" , NULL,
0x02
> > },
> > > > > { "SEAGATE" , "ST41601N" , "0102",
0x02
> > },
> > > > > { "SEAGATE" , "ST3655N" , NULL,
0x08
> > },
> > > > > { "SEAGATE" , "ST3390N" , NULL,
0x08
> > },
> > > > > { "SEAGATE" , "ST12550N" , NULL,
0x08
> > },
> > > > > { "SEAGATE" , "ST32430N" , NULL,
0x08
> > },
> > > > > { "SEAGATE" , "ST31230N" , NULL,
0x08
> > },
> > > > > { "SEAGATE" , "ST15230N" , NULL,
0x08
> > },
> > > > > { "SyQuest" , "SQ5110" , "CHC",
0x03
> > },
> > > > > { "TOSHIBA" , "MK538FB" , "60",
0x01
> > },
> > > > > { NULL , NULL , NULL,
0x0
> > }
> > > > > };
> > > > >
> > > > > Regards,
> > > > > Slobodan
> > > > >
> > > > >
> > > > > // HackDisableWriteCache
> > > > > // CLASS_SPECIAL_DISABLE_WRITE_CACHE
> > > > >
> > > > > "Bernhard" <> wrote in message
> > > > news:...
> > > > > > Hi Slobodan,
> > > > > >
> > > > > > - Setting HackMask=1 (in "...\Device Parameters\Classpnp"
key)
> > > > > > did not help.
> > > > > >
> > > > > > - Setting SpecialFlags=8 (in "...\Device Parameters\disk"
key)
> > > > > > had the effect that I could not enable write caching in the
> > > > > > properties dialog any more (which would be OK), but did not
> > > > > > help either.
> > > > > > (This idea stems from the following DDK source line
> > > > > > #define HackDisableWriteCache (0x08)
> > > > > >
> > > > > > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > > > > > I was able to persistently change the DeviceHotplug value
to 1
> > > > > > for the CF device, but this did not help, too.
> > > > > > The MediaRemovable value is still 0 (it is 1 for the USB
> > > > > > stick), and I it seems I just can't let Windows treat the
CF
> > > > > > card like a removable hotplug device :-(
> > > > > >
> > > > > > Thanks for your help anyway
> > > > > > Bernhard
> > > > > >
> > > > > >
> > > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > > Hi Bernhard,
> > > > > > >
> > > > > > > Few facts from DDK:
> > > > > > > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > > > > > > 2.
> > > > > > > #define CLASSP_REG_HACK_VALUE_NAME
(L"HackMask")
> > > > > > > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > > > > > (L"WriteCacheEnableOverride")
> > > > > > > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > > > > > (L"UserRemovalPolicy")
> > > > > > >
> > > > > > > 3. There is WriteCacheEnableOverride but this is override
> > that is
> > > > > > used to enable and not to disable caching in filesystems.
> > > > > > > 4. UserRemovalPolicy of 3 with override and set flag
> > > > DeviceHotplug to
> > > > > > true.
> > > > > > > 5. This is from DDK classpnp implementation. Comment in
code
> > > > speak
> > > > > > for itself:
> > > > > > > //
> > > > > > > // this refers to devices which, for reasons not yet
> > > > understood,
> > > > > > > // do not fail PREVENT_MEDIA_REMOVAL requests even
though
> > > > they
> > > > > > > // have no way to lock the media into the drive.
this
> > allows
> > > > > > > // the filesystems to turn off delayed-write caching
for
> > > > these
> > > > > > > // devices as well.
> > > > > > > //
> > > > > > >
> > > > > > > if
(TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > > > > > > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > > > > > > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > > > > > > } else {
> > > > > > > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > > > > > > }
> > > > > > >
> > > > > > > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA
> > (0x00000001)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To conclude this try playing with registry value
"HackMask"
> > bit
> > > > 0.
> > > > > > Let us know if this helped.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Slobodan
> > > > > > >
> > > > > > >
> > > > > > > <> wrote in message
> > > > > >
news:...
> > > > > > > > Hi Slobodan,
> > > > > > > >
> > > > > > > > yes, I used regedit, restarted the computer, and the
value
> > > > remained
> > > > > > > > unchanged.
> > > > > > > > Here is how the regedit export looks like:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > > > > > > Parameters\Classpnp]
> > > > > > > > "UserRemovalPolicy"=dword:00000003
> > > > > > > >
> > > > > > > > When I test with a USB stick with activated "optimize
for
> > quick
> > > > > > > > removal"
> > > > > > > > switch, there are no problems with sudden power off.
> > > > > > > > But for the compact flash card (and here I need this
> > feature!),
> > > > > > > > tests show that files get corrupted, even with the
above
> > > > registry
> > > > > > > > setting.
> > > > > > > >
> > > > > > > > I wrote a small tool to flush buffers (uses
> > FlushFileBuffers),
> > > > > > > > and this works, but it would be much better to have a
mode
> > > > where
> > > > > > > > flushing is done automatically, even at the cost of
> > performance
> > > > > > > > decrease.
> > > > > > > > (Obviously this mode exists, as the experience with the
USB
> > > > stick
> > > > > > > > shows...)
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Bernhard
> > > > > > > >
> > > > > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > > > > Hi Bernhard,
> > > > > > > > >
> > > > > > > > > If you can't make it work trough registry then inf
file
> > will
> > > > not
> > > > > > do
> > > > > > > > you any good :-(
> > > > > > > > > I assume that you used regedit for finding and
setting
> > value
> > > > in
> > > > > > > > registry, right?
> > > > > > > > > Have you restarted computer after the change?
> > > > > > > > > Also make sure that value remained unchanged.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Slobodan
> > > > > > > > >
> > > > > > > > > <> wrote in message
> > > > > > > >
> > news:...
> > > > > > > > > > Hi Slobodan,
> > > > > > > > > >
> > > > > > > > > > I also have problems with write caching and tried
your
> > > > registry
> > > > > > > > patch,
> > > > > > > > > > but without success.
> > > > > > > > > > Can you give me some details about the "hack"
solution?
> > > > (modify
> > > > > > > > > > disk.inf)
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Bernhard
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >

 

Hi Bernhard,

Since we are dealing with embedded here if all other suggestion fail, you have one more option on your disposal.
In DDK you have working disk driver example. So you can modify it to flush all request when you want them (always).

Regards,
Slobodan


"Bernhard" <> wrote in message news:...
> Konstantin,
>
> I did not yet get the dskcache tool but I will check this, too.
> Thank you for the link, it contains the best information that I have
> read about this issue so far. And it seems that the FlushFileBuffers
> API is indeed the only way to insure proper cache flushing...
>
> And I am somewhat relieved when I read the following:
> "Writing to the registry is an example of an operation that results
> in the FlushFileBuffers API being called and the SYNCHRONIZE CACHE
> command being sent to the disk."
> So at least internally in Windows, they seem to know how to do it...
>
> Regards,
> Bernhard
>
> KM wrote:
> > Bernhard,
> >
> > Here is an idea for you that you might have already tried but still
> worth to mention...
> >
> > With W2K SP3 MS introduced the "Power Protected" Write Cache Option
> in additon to the "Write Caching" option.
> > Basically, to have the FS driver to issue Flush/Write-Through
> commands you will need to set "Write Caching" option to Enabled and
> > the "Power Protected" option to Disabled (see more info here:
> http://support.microsoft.com/?kbid=332023).
> >
> > Instead of messing up with API for the moment you can try the easiest
> way - use RK utility diskcache (some info here
> > http://support.microsoft.com/kb/811392/EN-US)
> >
> > If it helps, let us know.
> >
> > --
> > Regards,
> > KM, BSquare Corp.
> >
> >
> > > Hi Slobodan,
> > >
> > > I did all previous tests with NTFS with compression.
> > >
> > > Now I prepared a CF disk with FAT and tested again
> > > (The test is: recursively copy a directory tree
> > > from network drive to disk, then (optionally) do
> > > FlushFileBuffers, then cut power off, reboot, compare
> > > files on disk to files on network. Autochk is enabled.)
> > > With FAT things are even worse:
> > > Without FlushFileBuffers, chkdsk complains about lost
> > > clusters and creates some *.chk files, but the original
> > > files are completely missing.
> > > With FlushFileBuffers, everything is OK.
> > >
> > > With NTFS, and without FlushFileBuffers, the situation
> > > is as follows:
> > > chkdsk detects no errors, all files look OK at first glance,
> > > (file length, modification time etc. are OK),
> > > but usually one file (not always the same!) consists of
> > > binary zeros from some offset on. That means that the
> > > NTFS "metadata" is OK, but the user data (file contents)
> > > is corrupted...
> > >
> > > So it seems that our only rescue is FlushFileBuffers!
> > > The problem is not with our own application which we
> > > can modify easily, it's with 3rd party SW (e.g. FTP
> > > server, ZIP file extractor, ...) where it would be best
> > > if flushing occurs at least if a file is closed.
> > >
> > > Regards,
> > > Bernhard
> > >
> > > Slobodan Brcin (eMVP) wrote:
> > > > Hi Bernhard,
> > > >
> > > > First do you use NTFS or FAT?
> > > > I think that NTFS was not created to work on removable disks so
> it
> > > might not flush data on its own. FAT actually flushed data on
> > > > removable disks.
> > > >
> > > > Now when you mention this, I remembered that there was a
> discussion
> > > on this subject although I can't find the right thread :-(
> > > > Anyhow you can't do anything to disk internal caching trough MS
> > > registry switches, but rather trough sending proprietary SCSI codes
> > > > to disk device to disable caching or to alter internal caching
> > > behavior.
> > > >
> > > > If you get corruption when you press reset button then this is
> > > windows software issue.
> > > > If you get corruption when you cut power then this might be
> internal
> > > disk caching problem.
> > > >
> > > > Optimize for quick removal will try to pass all write request to
> disk
> > > controller as they come, with minimum or no delay. Also it
> > > > should have different behavior with regards on dirty bit.
> > > >
> > > >
> > >
> http://groups-beta.google.com/group..._frm/thread/0a00a67f882086c7#4ee475b3e0c63a48
> > > >
> > >
> http://groups-beta.google.com/group..._frm/thread/a692df61fb93fb8d#4a434eecc6c89102
> > > >
> > > >
> > > > Regards,
> > > > Slobodan
> > > >
> > > >
> > > > "Bernhard" <> wrote in message
> > > news:...
> > > > > Hi Slobodan,
> > > > >
> > > > > the registry value UserWriteCacheSetting=0x0 is automatically
> > > > > created when I un-check the "Enable write caching on the disk"
> > > > > check-box in the properties GUI.
> > > > > That was of course what I tried first, but it had no effect on
> > > > > the corrupted file problems after power down.
> > > > >
> > > > > I don't know much about caching issues, but I conclude from the
> > > > > explanation for the "Optimize for quick removal" switch in the
> GUI
> > > > > ("This setting disables write caching on the disk and in
> Windows,
> > > ...")
> > > > > that there are two levels of write caching: hardware level and
> > > Windows
> > > > > level. The UserWriteCacheSetting value seems to have effect
> only on
> > > > > hardware level caching. (But this is actually only
> speculation...)
> > > > >
> > > > > At the moment I think I have to fall back on a tool that calls
> > > > > FlushFileBuffers every 5 seconds or so - not very satisfactory,
> > > > > but I hope this will reduce the errors considerably.
> > > > >
> > > > > Regards,
> > > > > Bernhard
> > > > >
> > > > >
> > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > Try:
> > > > > >
> > > > > > UserWriteCacheSetting:
> > > > > >
> > > > >
> > >
> http://groups-beta.google.com/groups?q=UserWriteCacheSetting&qt_s=Search+Groups
> > > > > >
> > > > > > I have no idea where you dig out "SpecialFlags" key but look
> at
> > > the
> > > > > following that only mention value that you use, this is
> > > > > > hardcoded hack for specific disk models.
> > > > > >
> > > > > > Following call set entries that you mention:
> > > > > > ClassScanForSpecial(fdoExtension, DiskBadControllers,
> > > > > DiskSetSpecialHacks);
> > > > > >
> > > > > >
> > > > > > And as you can see DiskBadControllers is hardcoded.
> > > > > >
> > > > > > CLASSPNP_SCAN_FOR_SPECIAL_INFO DiskBadControllers[] = {
> > > > > > { "COMPAQ" , "PD-1" , NULL,
> 0x02
> > > },
> > > > > > { "CONNER" , "CP3500" , NULL,
> 0x02
> > > },
> > > > > > { "FUJITSU" , "M2652S-512" , NULL,
> 0x01
> > > },
> > > > > > { "HP ", "C1113F " , NULL,
> 0x20
> > > },
> > > > > > // iomegas require START_UNIT commands so be sure to
> match
> > > all of
> > > > > them.
> > > > > > { "iomega" , "jaz" , NULL,
> 0x30
> > > },
> > > > > > { "iomega" , NULL , NULL,
> 0x20
> > > },
> > > > > > { "IOMEGA" , "ZIP" , NULL,
> 0x27
> > > },
> > > > > > { "IOMEGA" , NULL , NULL,
> 0x20
> > > },
> > > > > > { "MAXTOR" , "MXT-540SL" , "I1.2",
> 0x01
> > > },
> > > > > > { "MICROP" , "1936-21MW1002002" , NULL,
> 0x03
> > > },
> > > > > > { "OLIVETTI", "CP3500" , NULL,
> 0x02
> > > },
> > > > > > { "SEAGATE" , "ST41601N" , "0102",
> 0x02
> > > },
> > > > > > { "SEAGATE" , "ST3655N" , NULL,
> 0x08
> > > },
> > > > > > { "SEAGATE" , "ST3390N" , NULL,
> 0x08
> > > },
> > > > > > { "SEAGATE" , "ST12550N" , NULL,
> 0x08
> > > },
> > > > > > { "SEAGATE" , "ST32430N" , NULL,
> 0x08
> > > },
> > > > > > { "SEAGATE" , "ST31230N" , NULL,
> 0x08
> > > },
> > > > > > { "SEAGATE" , "ST15230N" , NULL,
> 0x08
> > > },
> > > > > > { "SyQuest" , "SQ5110" , "CHC",
> 0x03
> > > },
> > > > > > { "TOSHIBA" , "MK538FB" , "60",
> 0x01
> > > },
> > > > > > { NULL , NULL , NULL,
> 0x0
> > > }
> > > > > > };
> > > > > >
> > > > > > Regards,
> > > > > > Slobodan
> > > > > >
> > > > > >
> > > > > > // HackDisableWriteCache
> > > > > > // CLASS_SPECIAL_DISABLE_WRITE_CACHE
> > > > > >
> > > > > > "Bernhard" <> wrote in message
> > > > > news:...
> > > > > > > Hi Slobodan,
> > > > > > >
> > > > > > > - Setting HackMask=1 (in "...\Device Parameters\Classpnp"
> key)
> > > > > > > did not help.
> > > > > > >
> > > > > > > - Setting SpecialFlags=8 (in "...\Device Parameters\disk"
> key)
> > > > > > > had the effect that I could not enable write caching in the
> > > > > > > properties dialog any more (which would be OK), but did not
> > > > > > > help either.
> > > > > > > (This idea stems from the following DDK source line
> > > > > > > #define HackDisableWriteCache (0x08)
> > > > > > >
> > > > > > > - I then played around with IOCTL_STORAGE_SET_HOTPLUG_INFO:
> > > > > > > I was able to persistently change the DeviceHotplug value
> to 1
> > > > > > > for the CF device, but this did not help, too.
> > > > > > > The MediaRemovable value is still 0 (it is 1 for the USB
> > > > > > > stick), and I it seems I just can't let Windows treat the
> CF
> > > > > > > card like a removable hotplug device :-(
> > > > > > >
> > > > > > > Thanks for your help anyway
> > > > > > > Bernhard
> > > > > > >
> > > > > > >
> > > > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > > > Hi Bernhard,
> > > > > > > >
> > > > > > > > Few facts from DDK:
> > > > > > > > 1. RemovalPolicyExpectSurpriseRemoval = 3
> > > > > > > > 2.
> > > > > > > > #define CLASSP_REG_HACK_VALUE_NAME
> (L"HackMask")
> > > > > > > > #define CLASSP_REG_WRITE_CACHE_VALUE_NAME
> > > > > > > (L"WriteCacheEnableOverride")
> > > > > > > > #define CLASSP_REG_REMOVAL_POLICY_VALUE_NAME
> > > > > > > (L"UserRemovalPolicy")
> > > > > > > >
> > > > > > > > 3. There is WriteCacheEnableOverride but this is override
> > > that is
> > > > > > > used to enable and not to disable caching in filesystems.
> > > > > > > > 4. UserRemovalPolicy of 3 with override and set flag
> > > > > DeviceHotplug to
> > > > > > > true.
> > > > > > > > 5. This is from DDK classpnp implementation. Comment in
> code
> > > > > speak
> > > > > > > for itself:
> > > > > > > > //
> > > > > > > > // this refers to devices which, for reasons not yet
> > > > > understood,
> > > > > > > > // do not fail PREVENT_MEDIA_REMOVAL requests even
> though
> > > > > they
> > > > > > > > // have no way to lock the media into the drive.
> this
> > > allows
> > > > > > > > // the filesystems to turn off delayed-write caching
> for
> > > > > these
> > > > > > > > // devices as well.
> > > > > > > > //
> > > > > > > >
> > > > > > > > if
> (TEST_FLAG(FdoExtension->PrivateFdoData->HackFlags,
> > > > > > > > FDO_HACK_CANNOT_LOCK_MEDIA)) {
> > > > > > > > fdoData->HotplugInfo.MediaHotplug = TRUE;
> > > > > > > > } else {
> > > > > > > > fdoData->HotplugInfo.MediaHotplug = FALSE;
> > > > > > > > }
> > > > > > > >
> > > > > > > > 6. #define FDO_HACK_CANNOT_LOCK_MEDIA
> > > (0x00000001)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > To conclude this try playing with registry value
> "HackMask"
> > > bit
> > > > > 0.
> > > > > > > Let us know if this helped.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Slobodan
> > > > > > > >
> > > > > > > >
> > > > > > > > <> wrote in message
> > > > > > >
> news:...
> > > > > > > > > Hi Slobodan,
> > > > > > > > >
> > > > > > > > > yes, I used regedit, restarted the computer, and the
> value
> > > > > remained
> > > > > > > > > unchanged.
> > > > > > > > > Here is how the regedit export looks like:
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskSanDisk_SDCFBI-256______________________HDC_2.13\4&6cb4d8c&0&0.0.0\Device
> > > > > > > > > Parameters\Classpnp]
> > > > > > > > > "UserRemovalPolicy"=dword:00000003
> > > > > > > > >
> > > > > > > > > When I test with a USB stick with activated "optimize
> for
> > > quick
> > > > > > > > > removal"
> > > > > > > > > switch, there are no problems with sudden power off.
> > > > > > > > > But for the compact flash card (and here I need this
> > > feature!),
> > > > > > > > > tests show that files get corrupted, even with the
> above
> > > > > registry
> > > > > > > > > setting.
> > > > > > > > >
> > > > > > > > > I wrote a small tool to flush buffers (uses
> > > FlushFileBuffers),
> > > > > > > > > and this works, but it would be much better to have a
> mode
> > > > > where
> > > > > > > > > flushing is done automatically, even at the cost of
> > > performance
> > > > > > > > > decrease.
> > > > > > > > > (Obviously this mode exists, as the experience with the
> USB
> > > > > stick
> > > > > > > > > shows...)
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Bernhard
> > > > > > > > >
> > > > > > > > > Slobodan Brcin (eMVP) wrote:
> > > > > > > > > > Hi Bernhard,
> > > > > > > > > >
> > > > > > > > > > If you can't make it work trough registry then inf
> file
> > > will
> > > > > not
> > > > > > > do
> > > > > > > > > you any good :-(
> > > > > > > > > > I assume that you used regedit for finding and
> setting
> > > value
> > > > > in
> > > > > > > > > registry, right?
> > > > > > > > > > Have you restarted computer after the change?
> > > > > > > > > > Also make sure that value remained unchanged.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Slobodan
> > > > > > > > > >
> > > > > > > > > > <> wrote in message
> > > > > > > > >
> > > news:...
> > > > > > > > > > > Hi Slobodan,
> > > > > > > > > > >
> > > > > > > > > > > I also have problems with write caching and tried
> your
> > > > > registry
> > > > > > > > > patch,
> > > > > > > > > > > but without success.
> > > > > > > > > > > Can you give me some details about the "hack"
> solution?
> > > > > (modify
> > > > > > > > > > > disk.inf)
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Bernhard
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>