>I was serious :-) Really. Knowing Jim's extensive research on the subject, I thought he'd be delighted. Makes one wonder why it was done any differently in the past...
>
>Let us know how the testing goes. The MSDN library isn't very revealing on the matter.

The help says FLUSH now calls the FlushFileBuffers API function... like you say, if it wasn't doing this before, exactly what WAS it doing?

If by MSDN Library you're referring to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/flushfilebuffers.asp then yeah, it's not too enlightening.

I think ultimately it has to depend on the device driver for the disk subsystem in question, and if/how well it implements FFB. The driver would absolutely have to respect FFB if called with a volume option because that's what must get called on a system shutdown. Would it respect FFB called with a single file or group of files as argument(s)? (a group of files might be treated in VFP as multiple single-file calls).

I'd like to think if it respects the former, it *should* respect the latter. But, in a commodity market OEMs might be trying to differentiate themselves from the competition on benchmarks. It's possible they could show higher numbers if they ignored single-file FFB calls and simply left it up to a lazy-write algorithm to take care of it "whenever".

To a certain extent nVidia and ATI have been engaging in dodgy optimizations to make their video cards look better in the fiercely competitive graphics world.