This issue has interested me and I've tried to keep track of all posts here on this subject. AFAIK there has never been an official explanation from MS about what was happening and when it was fixed. However, this is what I've been able to gather:

Platform: W2K SP1 or lower, IDE hard drive(s) (or SCSI on Adaptec 2940 controller, reported by Andrew Stapleton), write-behind caching enabled

Behaviour: Modified VFP6/7 form files (.SCT/.SCX) are never actually committed to disk until a normal shutdown of the machine is performed. This is true even if the disk subsystem is not busy and the VFP development environment has been shut down normally several hours earlier.

This has two major effects:

1. If the machine crashes or shuts down abnormally, changes to these files are lost. Some developers leave their machines running (nominally) 24/7, i.e. they are never "normally" shut down, so the potential for data loss is large.

2. Between a shutdown of VFP and a normal shutdown of the machine, some third-party software e.g. CD-burners, cannot read the modified files to copy and/or back them up. Again, this problem is exacerbated if the machine is run 24/7 and not normally shut down.

The recommended workaround was to disable write-behind caching on the drive(s) in question. While effective, this workaround itself was affected by a second bug - the one you outline, where the write-behind cache setting does not "stick" between boots, and must be reset each time the computer is restarted.

Again, while emphasizing that I've never seen a definitive post from MS on this issue, I gather the fundamental problem was fixed in a hotfix to W2K SP1, which would have been included in SP2 and SP3:

W2K SP1 Write Cache Hotfix from MS Thread #491641 Message #491641

and, as a consequence, the workaround of disabling the write behind cache should no longer be necessary, whether or not the disabled setting "sticks" between boots.

Personally, I have never encountered the data loss problem. My machine is very stable and runs off a UPS, and it rarely runs more than 8 hours or so between restarts. I have write behind caching enabled because I prefer maximum performance.

If one's computer is less than stable, or subject to power fluctuations it may help to disable write behind caching - but it is by no means a sure-fire preventative. Far better to address the root problem(s), rather than symptoms.

P.S. I started the above-quoted thread 18 months ago. The MSKB article appears to have been updated from when I first viewed it - it now claims the issue was not addressed until SP3. The way I read it, the issue is different from what I remember, and have outlined above. I wonder whether MS found yet another issue that was rolled into this fix and/or SP3.