Comment 67 for bug 317781

It's easy to lay the blame on "crappy" applications, but the fact of the matter is that it is really the interface that sucks here. Using the notation of comment #54, what applications really want is execute (1) atomically. Then it shouldn't matter whether they rewrite their files every minute or every second, because the file system could still decide when to actually commit this to disc. I always assumed, naively perhaps, that (2) did essentially that, though that is of course not the case if the file system decides to commit the result of (2e) before (2c) and (2d).

So what is an application that rewrites a file (possibly not as the result of direct user action) supposed to do? You suggest (3), but I can see a few drawbacks:
* If the file is overwritten twice in short succession, you'll get gratuitous disc writes. This is the least of the problems and can be worked around inside the app by using a timer.
* fsync is expensive. If your application can't afford to make a system call that can potentially block for on the order of a second, you're going to have to offload fsync to a seperate thread. Not impossible, but not entirely trivial either.
* Calling fsync on a c++ ofstream looks like a major pita.