ofstream, fsync and data loss bugs

[Pavel Sanda <ps at twin dot jikos dot cz>]

Hello,

in the recent uprise of ext4 new kind of dataloss bug appeared.
In short if you

1. open file, with trunc flag
2. write something to it
3. close the file

then truncation of file can be moved with metadata to disk, while the
actual write of data happens (much) later on. If you run out of power
supply or get OS crash then you won't find neither old file nor
new one, but zero-sized file. If the application make the mistake 
that it does backuping via copy and not move, then you will find two
nice zero files after reboot.

As suggested, there should be point "2.5 fsync the file" before
closing it, cf.
http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

Now my question is, what to do if one uses STL code, like:
{
  ofstream ofs(filename, ios::out|ios::trunc);
  retval = ofs && write(ofs);
}

There is no fsync() call for the stream, there is no direct access
to file descriptor, flush() is reported not to mimic fsync().

1. Is there some way how to force fsync()?
2. If not should be this considered as bug/enh request for libstdc++?

Thanks,
Pavel