> The problem is that *you can't* without calling fsync.
fsync() sucks because it is a "commit now" thing. Not everyone wants to commit now - I fully understand that. I'm a notebook user and I don't want my disk being spun up unnecessarily. But, current semantics are what they are, so ignoring them is looking for trouble elsewhere. Sucks - yes, but living in denial doesn't help either. And, as you say, not a great way to make our apps more awesome. Just a necessary evil right now. Some of it can be avoided with backup files, but the underlying badness will persist.
It would be nice to have a system call that guarantees "data before metadata, but not necessarily now", so that other systems interested in it may also implement it. Then the apps could comfortably rely on this when renaming files over the top of other ones. I was even thinking that we should ask POSIX to standardise that fsync(-fd) means exactly that (because fd is always positive, but we use int for it, which can also have negative values), but this may confuse things even more and is probably stupid.
Sure, some Linux file systems will continue making it more comfortable even with the undefined order of current semantics, which will please users (BTW, this is really interesting: http://lwn.net/Articles/326583/). But, the long term solution in the world of Unix should probably be a bit more inclusive.
PS. To be fair to fsync(), it is an indispensable tool for databases, so making it work as fast as possible is most definitely a good thing. What ext3 in ordered mode does with it an abomination.