That's Microsoft/Apple thinking: don't bother to get it right - just
make it featureful.  This is the reason why Apple *still* doesn't have
memory protection in their primary O.S. offering, ten years after they
first could have shipped it.   It used to blow my mind when I talked
to Windows users and they would tell me about having to reboot their
system two or three times a day, and lose hours of work in the
process.   This problem is just the same - the only think that's
different about it is how often it's likely to happen.

End users should not have to evaluate whether or not some aspect of a
system is risky.  It should just work.  There should be no risk, at
least in cases where it's possible for there to be no risk.  For the
operating system to claim that a write is complete when it's not
creates a risk that no application programmer would have reason to
expect, and *that* creates a risk that no end user would have reason
to expect.  The fact that this might only bite the end user once, or
might only bite one random end user out of ten, is cold comfort to the
one who gets bitten.

When giving advice as to what operating system to choose, a good basis
for that advice is the determination that the end user to whom the
advice is being given will not be taking a significant risk of some
unexpected sort of lossage as a result of taking the advice.   So if
in fact Manuel is correct in saying that fsync on Linux doesn't work
correctly, I think this is a good reason to advise people to use
NetBSD instead of Linux.

However, given that companies like IBM and SGI have jumped onto the
Linux bandwagon, I suspect that the problem with fsync will be cured
soon, probably in Linux 2.4.   It's simply not acceptable in a
production operating system being used to do real work.

			       _MelloN_