Comment 6 for bug 713832

Hi there..

I ran into the same error:

gpg: fatal: zlib inflate problem: invalid stored block lengths
secmem usage: 2336/2720 bytes in 5/9 blocks of pool 3904/32768

and I am on a debian system (lenny 2.6.26-2-amd64)

GPG error detail: Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1245, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1238, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1139, in main
    sync_archive()
  File "/usr/bin/duplicity", line 953, in sync_archive
    copy_to_local(fn)
  File "/usr/bin/duplicity", line 913, in copy_to_local
    size=sys.maxint)
  File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 331, in GzipWriteFile
    new_block = block_iter.next(min(128*1024, bytes_to_go))
  File "/usr/bin/duplicity", line 894, in next
    self.fileobj.close()
  File "/usr/lib/python2.5/site-packages/duplicity/dup_temp.py", line 210, in close
    assert not self.fileobj.close()
  File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 198, in close
    self.gpg_failed()
  File "/usr/lib/python2.5/site-packages/duplicity/gpg.py", line 165, in gpg_failed
    raise GPGError, msg
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 1024-bit ELG-E key, ID 752CCE08, created 2010-12-23
"sn56482 (Swissnas Customer sn56482 Key)"
gpg: fatal: zlib inflate problem: invalid stored block lengths
secmem usage: 2336/2720 bytes in 5/9 blocks of pool 3904/32768
===== End GnuPG log =====

GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: encrypted with 1024-bit ELG-E key, ID 752CCE08, created 2010-12-23
"masked"
gpg: fatal: zlib inflate problem: invalid stored block lengths
secmem usage: 2336/2720 bytes in 5/9 blocks of pool 3904/32768
===== End GnuPG log =====

11:09:38.043 Task 'BKP' failed with exit code '31'.
--- Finished state FAILED 'code 31' at 11:09:38.043 - Runtime 00:09:32.317 ---

Looks as if one of the files which is being downloaded by duplicity cannot be decompressed... If I could figure out which it is I could delete it on the server and duplicity would at least carry on backupping.
Did you find a workaround?