Subject: bug#22768: Crash safety

From: Antonio Diaz Diaz <[email-masked]>
Date: Sat, 27 Feb 2016 16:47:06 +0100

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.