The normal behavior of the MS-DOS® Commit function was to flush all unwritten data for a particular file to disk, and wait until the data had been confirmed as written before returning. With the Disable Synchronous Buf­fer Commits option checked, the call would return immediately, rather than waiting for the data to be written. This, of course, was a violation of the functional specification, which requires that the call not return until the data has been written. This increased the risk of what Knowl­edge Base article 139669 euphemistically calls "file integrity problems" since it caused the program that issued the flush request to think that the data was safely on disk when it really wasn’t.

A database program may use the Com­mit function to establish points at which the state of the file on disk is in agreement with what the program expects to be on the disk. If the computer loses power during an update, the database program can use the information recorded at the last commit point to re-establish the integrity of the database. If Commit returned immediately before the commit was complete, then this integrity checkpoint would be lost. The result was that your database became corrupted.

Why was this option available if the consequences were so awful? The reason: a bug in Windows® 3.11.

Windows 3.11 introduced "32-bit file access," which was a 32-bit implementation of the low-level file I/O interface. But the implementation of the Commit function contained a bug that effectively ignored requests to flush file buffers. If you took a program that flushed its file buffers and ran it on Windows 3.11, the flush call had no effect. As a result, if you lost power at just the wrong time, you ended up with a corrupted database.

The folks working on the Windows 95 file system fixed this bug, but new bug reports started to trickle in. Somebody’s accounts payable program started running really slowly. Then somebody else’s database program did the same. What was going on?

It turned out that these programs constantly issued flush calls. The programmers noticed that flush calls were really fast on Windows 3.11, so they sprinkled them liberally throughout their program. Write a byte, flush. Write a string, flush. Since the flushes were so fast, the app could commit the data to disk after every operation with no noticeable performance degradation. But once Windows 95 fixed the bug, these programs started to run very slowly since the Commit calls were suddenly doing actual work.

Of course, if the file system team had done nothing, these programs would have continued to run slowly and users would have jumped to the conclusion that Windows 95 was the problem. "Windows 95 runs like a dog," they would tell others. On the other hand, if the file system returned to the old Windows 3.11 behavior, they would have been reintroducing a bug that could lead to those pesky "file integrity problems."

So they concluded that the solution was to leave the bug fixed but add a check-box—albeit buried in the Troubleshooting page—to return to the Windows 3.11 behavior for those people who were running programs that encountered problems due to the bug being fixed.

It turned out that history repeated itself. In Windows Server® 2003, the I/O folks found a bug where requests tagged as Forced Unit Access (FUA) would lose the FUA tag and be performed as normal I/O. It was the modern-day version of ignoring flush requests! They fixed the bug but left an option to return to the old buggy behavior. The Windows Server 2003 version of this checkbox is called "Enable Advanced Performance," but now you know it really just means "Restore old buggy behavior."