bug#22768: Crash safety

[Paul Eggert]

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.