[Top][All Lists]

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

bug#22768: Crash safety

From: Paul Eggert
Subject: bug#22768: Crash safety
Date: Mon, 29 Feb 2016 11:43:41 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 02/29/2016 09:12 AM, Antonio Diaz Diaz wrote:
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

That approach does not suffice, because 'sync' does not guarantee that the output data has been synchronized to disk.

I know, but how can you guarantee that 'gzip --synchronous' will work on a system where the 'sync' above does not even guarantee that 'file.gz' is written to disk before 'file' is deleted?

Yes, I can guarantee that 'gzip --synchronous' will not lose data on any system conforming to POSIX with the Synchronized Input and Output option. No such guarantee can be made for the above shell script, because the 'sync' command does not make the same guarantees that the 'fsync' function does. Putting the above shell script into the documentation would give users a false sense of security. (Or maybe we should put the above shell script into the documentation as an example of what *not* to do. :-)

The next one might be titled "On why 'gzip --synchronous' does not work on some filesystems".

:-) Of course the problem can still exist on file systems that do not conform to POSIX, and there are many of those. Still, there are people who take these things seriously, and who use file systems that are safe in the presence of crashes, and for these people grep --synchronous should work.

As you said, gzip has run unsafely for decades without a failure.

I did not say that! And I am skeptical that it's true. I think it's quite possible that gzip has lost data when an operating system crashed at the wrong moment.

reply via email to

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