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.
