>>I've noticed a recent rash of "Delayed write failure" messages here. This may be a consequence of the OS just accepting the FLUSH and returning (as SUCCESSFUL) to the application! The OS may well have some problem AFTER it returns to the application, but since it has already told the application that the write was OK it informs it using this error message.
>
>My question is: if the server is "caching writes", and I have "another" work station that does a lock on a "cached record", what "version" of the record is that station locking (and returning to the work station) ? The one in the cache or the one on the HD ? Or will the Server now start "writing", before it starts locking ? And when does all this "virtual BS" finally start to implode.

Well all this "Delayed write failure" attribution is pure SPECULATION on my part. That the error message includes 'save the file elsewhere' suggests that EITHER:
1) the buffered data is no longer available, OR...
2) the buffered data IS available BUT the application is assumed (correctly, I would say) to have proceeded on the basis of a NON-ERROR return to it upon issuing a write so it is impossible (and UNSAFE) to 'go backwards'.

I think we're all generally impressed with Windows' cacheing, though we know very little of its details. But I also worry about things like this one. In particular I worry that MS may use totally different I/O mechanisms for products like SQL Server versus regular run-of-the-mill products. If this is anywhere near the case then we could be heading for trouble.

I'm getting one strong feeling though, and that is that our MS software engineers amy have gone too far already in the quest for speed in the "regular user" platforms.
And an implosion amy be on the way.