There's a bug report about data loss due computer losing power. fsync()
or fdatasync() in xz would quite likely have avoided the data loss.
https://bugs.debian.org/814089
I considered adding fsync() to xz a long ago (it probably was before
5.0.0). I didn't add it because it had a huge performance impact when
compressing many small files, and that downside still exists. gzip and
bzip2 don't use fsync(). On the other hand, performance doesn't matter
so much if there's a too high chance of data loss.
If fsync() was added, I suppose it would be enough to call it when the
source file is about to be deleted. That is, if writing to stdout or
using --keep, fsync() could be skipped. Adding a new command line
option to xz to enable/disable fsync() doesn't sound great.
Some people don't like that xz (and other such tools that delete input
files) doesn't call fsync(). If I change it, I'm sure that some other
people won't like it because their xz use case got horribly slow. So I
cannot make everyone happy.
Currently I'm slightly in favor of keeping the existing non-fsync()
behavior unchanged. It would be nice to hear other people's opinions on
this. Thanks!
--
Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
