Unfortunately, it's often not that simple on POSIX systems; it's quite common for disk controllers to disobey fsync, for instance, either in their drivers or in their hardware caches or both. I'm actually surprised Apple is even willing to make the guarantees above about F_FULLFSYNC; I'd read it as, at best, only applying to Apple hardware, as if a third-party controller is doing something silly they can't really do much about that.

In other words, what the osx default fsync() semantics is useful for? I had the same discussion on Twitter a few days ago...

It is useful for forcing all writes out to the storage device. If you device is battery/UPS backed, has enough capacity to flush its buffers (to disk or to flash memory) after a power loss, that is sufficient to (eventually) get your data on disk (yes,the drive may fail, but if that happens after the data has hit the platter, you have no guarantees, either)

From what I understand, that behaviour is in spec (for me, borderline, at best, but I don't make that spec) according to http://pubs.opengroup.org/onlinepubs/009695399/functions/fsy... ("physical write from the buffer cache", not "physical write to the disk") and, AFAIK, is what others do, too (http://ridiculousfish.com/blog/posts/mystery.html)

Edit: http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072..., referenced from that ridiculous fish post, gives more background info.

Ok makes sense in special cases indeed, however a really unsafe default...