Achieving that guarantee is not impossible, but it needs to be explicit. It can't be inferred from other API calls.
That's how you end up with stuff like OS X's "no really, fsync" param [1], or Motorola shipping nobarrier on their phones. [2]
[1] https://github.com/google/leveldb/issues/203#issuecomment-55...
[2] http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/
My memory is vulnerable to row hammer due to vendors cutting corners while pushing for increased DRAM density.
And my - supposedly - non-volatile storage is broken due to vendors gaming benchmarks with fsync.
Is there any component in a modern consumer computer that isn't fundamentally broken in one way or another?
Look at how much slower CPUs are without those speculative execution tricks. I can buy gigabytes of RAM with a 20 I found in an old jacket. You can explore entire worlds consisting of gigabytes of high res textures and mesh data in near real-time, while downloading 4 new albums off the internet.
Broken?
But do I care? All my computers, except the really ancient phone I use, are snappy.
Of course there are cases were CPU speed matters, but I don't know if they are any less obscure than the cases where timing attacks are a risk.
Yes, it is breaking the promise of what it is supposed to do. If fsync() was defined as "will ensure your data is on disk, unless that's kinda slow, then who knows", then the behaviour would not be broken, just potentially useless for many applications. But if you promise to ensure something is stored on disk, and then don't, that's the definition of being broken.
On windows FILE_FLAG_WRITE_THROUGH ("Write operations will not go through any intermediate cache, they will go directly to disk").
It's all there.
I agree with other poster, just cos you read back the file and it compared byte-for-byte, unless large it's likely to have come from the OS's RAM file cache.