Re: Bug#647522: non-deterministic compression results with gzip -n9

[Cyril Brulebois]

Cyril Brulebois <address@hidden> (08/02/2012):
> Playing on amd64:
> address@hidden:/tmp/ppl-0.11.2$ cp ../ppl-pristine/{CREDITS,README} .
> address@hidden:/tmp/ppl-0.11.2$ gzip -9nf CREDITS README
> address@hidden:/tmp/ppl-0.11.2$ ls -l *gz
> -rw-r--r-- 1 cbrulebois cbrulebois 6343 Feb  8 12:34 CREDITS.gz
> -rw-r--r-- 1 cbrulebois cbrulebois 8745 Feb  8 12:34 README.gz
> address@hidden:/tmp/ppl-0.11.2$ cp ../ppl-pristine/{CREDITS,README} .
> address@hidden:/tmp/ppl-0.11.2$ gzip -9nf README CREDITS
> address@hidden:/tmp/ppl-0.11.2$ ls -l *gz
> -rw-r--r-- 1 cbrulebois cbrulebois 6344 Feb  8 12:34 CREDITS.gz
> -rw-r--r-- 1 cbrulebois cbrulebois 8745 Feb  8 12:34 README.gz
> 
> It looks to me like it shouldn't be hard to figure out what happens here
> given the few tests I performed with the above command lines. On a few
> iterations, reproducibility (with a given input command line) doesn't
> seem to be an issue.

I think at least the attached patch won't hurt (when the DYN_ALLOC part
is fixed; and possibly turning that into a MEMSET-like macro).

And given dh_compress is passing files in an arbitrary order (it's using
“find” to detect files which needs to be compressed), I think we have
an explanation about the apparently-hard-to-reproduce issues.

Mraw,
KiBi.

gzip-zeroify-buffers.diff
Description: Text Data

signature.asc
Description: Digital signature