[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22768: Crash safety

From: Antonio Diaz Diaz
Subject: bug#22768: Crash safety
Date: Sat, 27 Feb 2016 16:47:06 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20070601 SeaMonkey/1.1.2

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]