Martin Steigerwald wrote:
> Am Donnerstag 12 März 2009 schrieb Eric Sandeen:
>> Filesystems can hack around some heuristics to try to make unsafe apps
>> safer, but in the end, it's the app's job to make sure a buffered write
>> hits permanent storage when it matters.
> Hmmm, okay. So here is:
> Feel free to add there. You'd need a bugzilla login tough.
Perhaps you can try this and add info if you like.
There is an environment variable KDE_EXTRA_FSYNC, put in with this
Do not paranoidly sync every time, it causes I/O performance problems
for some users. People who still want it for whatever reason like using
XFS can set $KDE_EXTRA_FSYNC to 1."
This is not "extra" - it is necessary if you actually want the data to
See also: http://lists.kde.org/?l=kde-devel&m=120880682813170&w=2
(note however that xfs is _not_ "zeroing just to be sure...")
int result = 0;
result = fflush(mStream); // We need to flush first otherwise
fsync may not have our data
while ((result == -1) && (errno == EINTR));
kWarning() << "K3TempFile: Error trying to flush " << mTmpName
" << strerror(errno);
mError = errno;
if (mFd >= 0)
if( qgetenv( "KDE_EXTRA_FSYNC" ) == "1" )
result = FDATASYNC(mFd);
kWarning() << "K3TempFile: Error trying to sync " <<
mTmpName << ": " << strerror(errno);
mError = errno;
return (mError == 0);
So somebody knew it was the right thing to do, but then turned it off,
probably because of ext3's painful behavior on fsync (see also: firefox
"bug" from a while ago)
what's interesting is that the sync() method isn't automatically called
from the other methods, near as I can tell, so it's up to the api user
to invoke it; and even then it only does fflush() not fsync() by
default, which doesn't actually push things to disk.
I'd suggest turning on this KDE_EXTRA_FSYNC and see how things go from
Although, the API refs say that this is deprecated in favor of
KTemporaryFile, and I find no reference whatsoever to "sync" of any kind