fatal: zlib inflate problem: invalid distance code

[João Grilo]

Hello again,

First of all, thanks for the quick reply.

The checksum did reveal that there are differences. I know this isn't
directly related to GnuPG, but since the file in question is so big
(100gigs), and I don't have physical access to the original file any more,
is it possible to simply transfer the difference between both binaries
through a network connection? If so, what would you consider the best option
in this situation? Rsync?

Thank you for your time, and I'll understand if you redirect me to the rsync
mailing list instead of providing an answer.

Best regards,
Joao Marques


On Jan 2, 2008 1:41 PM, John Clizbe <JPClizbe at tx.rr.com> wrote:

> João Grilo wrote:
> > Recently, I was asked to backup and archive a ton of sensitive data, so
> > I used gpg keep it away from evil eyes.
> >
> > Now, trying to recover it on a different machine, it fails with the
> > following error:
> > debian:~# gpg mybigbackupfile.tar.gz.gpg
> > gpg: CAST5 encrypted data
> > gpg: encrypted with 1 passphrase
> > -- correct password is typed --
> > gpg: fatal: zlib inflate problem: invalid distance code
> > secmem usage: 2048/2240 bytes in 4/5 blocks of pool 2240/32768
> >
> > I have no clue, since I have tried pretty much everything (including
> > installing the same operating system on the machine where I need to
> > decipher the data, using the "$ gpg < bigfile.gpg > bigfile" syntax and
> > so on). The error keeps showing up, and always stalls after processing
> > the same amount of data (aproximately 27 gigabytes).
> >
> > The weirdest part is that decrypting the data on the same machine it was
> > encrypted works perfectly. I have tried to replicate the environment
> > exactly (apart from a few packages which will probably be different, but
> > this is debian stable branch anyways). The only "big" difference, is the
> > hardware, but even the architecture is the same, the cpu is exactly
> alike.
>
> <OS details snipped>
>
> > Note that these are all amd64 binaries. The size of "mybigbackupfile" is
> > aproximately 105 gigabytes.
> >
> > If I can provide any additional information that can be useful to trace
> > the problem down, don't hesitate to ask.
>
> Since the original decrypts fine, I'd check and compare the hashes of the
> two
> encrypted archives.
>
> Small errors can creep in during transfer that will invalidate later
> decryption.
> Comparing the outputs from md5sum or sha1sum will alert you to the error.
>
> GnuPG may also be used to generate the file hashes:
>
>    gpg --print-md algo [files]
>
> algo may be taken from the listing produced by 'gpg --version'.
>
>    gpg --print-mds [files]
>
> will generate hashes for all available algorithms.
>
> Good luck.
>
> --
> John P. Clizbe                   Inet:   JPClizbe(a) tx DAWT rr DAHT con
> Ginger Bear Networks             hkp://keyserver.gingerbear.net
> "Be who you are and say what you feel because those who mind don't matter
> and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080102/ae1e7f91/attachment.htm>