GNU bug report logs - #22768
Crash safety

Previous Next

Package: gzip;

Reported by: Yanyan Jiang <jiangyy <at> outlook.com>

Date: Mon, 22 Feb 2016 16:02:02 UTC

Severity: normal

Merged with 22770

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #53 received at 22768 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Antonio Diaz Diaz <antonio <at> gnu.org>, 22768 <at> debbugs.gnu.org
Cc: Yanyan Jiang <jiangyy <at> outlook.com>
Subject: Re: bug#22768: Crash safety
Date: Mon, 29 Feb 2016 11:43:41 -0800
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.




This bug report was last modified 9 years and 74 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.