>>[...]and one that works if you remember to change the registry entry after every reboot[...]
>
>Hi Ed,
>
>can you reveal where that flag will be found in the registry? It might help me to expand my VFP startup script with a reset of that flag (usually I forget to do it manually). Or would you have objections against this approach?
>

It's going to vary from system to system based on how the system enumerates all the devices in your system; if you want to try this, use a product like CleanSweep that has a registry difference tool in it, turn off caching and run a baseline registry image, then turn on caching and run a difference check; it should find the registry key value that changed. The value is not a string like what the FFC registry class can handle, and there's other information in the binary key value that I have no clue about what it means. Each drive has its own entry in a separate key identified by a GUID. If you change the system configuration, the entry is likely to be assigned a new GUID - changing the SCSI ID assigned to a drive results in assigning a separate key in the registry for it, so I'd suspect the same would apply switching master/slave or channel settings.

It's also important that someone decides what actually causes the registry key not to stick, and why these files get mishandled. I'd hope that the underlying problem is addressed either within VFP or Win2K. The error is unusual since we aren't seeing the old data left on disk as a lost cluster, or garbage attached to the end of a file; the data is wiped, almost like a buffer was allocated to hold the deferred write but never filled, or the context of the buffer was wrong - a buffer was allocated and filled, and a pointer to it was set, but when it was time to write the data, the table that translates linear addresses into physical addresses for the wrong task was used. It's not a matter of partial corruption, which would be enough of a PITA by itself, but at least could be dissected and partly salvaged with a hex editor and some patience - the properties and method code are stored in the SCT as ASCII text. My encounter with the problem wiped out the SCT - if I hadn't saved it to VSS or another drive before it got lost, I'd have had nothing left behind to inspect; I went in with a hex editor and looked at the SCT, and it didn't leave anything useful behind, and Win2K did not report any file system errors, which I'd expect with typical file corruption from abnormal shutdown.

If it were just a matter of running a .REG file to update the registry during startup, someone would have probably released it by now. I certainly don't gain anything from not revealing the message hidden in specially marked packages of Snackie Cakes decrypted using my super-secret decoder ring...