Bob Proulx wrote:
Just now my preference is to make the behavior optional and call the option
--fsync. I think both points meet the principle of least surprise.
I would much prefer the above of an option to enable it rather than
one to disable it. Otherwise I have to go through workarounds to
avoid it in order to have the performance that used to be the default.
After thinking about it, I think that the right thing to do is to not
implement any kind of fsync functionality in gzip/lzip.
First, it may be a cause of feature creep. If gzip fsyncs the output
file it might also test it, or even compare it with the input file,
before deleting the input file.
Second, as doing it right in all circumstances may be impossible, it may
become an endless source of bug reports. (fsyncing also the
destination's directory, opening the output with O_DIRECT,...).
Third, it fights against other layers of the system, like the
filesystem, instead of collaborating with them.
Fourth, it fights against user's wishes instead of obeying them. If the
user chooses a fast-but-unsafe configuration for the filesystem, gzip
should not try to circumvent the user's choice, because gzip does not
know if the file being compressed is worth the trouble or not.
I think that the best way of guarding an important file against all bugs
and crashes is a extended version of the procedure already documented in
the manual of lzip:
1) gzip --keep file # don't delete input
2) sync # commit output and directory to disk
3) zcmp file file.gz # verify output
4) rm file # then remove input
Best regards,
Antonio.
