[Zope] Pack Not Working

[Tim Peters]

[Derek J. Balling ]
> Our Data.fs file is huge. We had a nightly process to pack it, but it
> seems that starting a few weeks ago, the nightly process now shows:
>
> ------
> 2004-11-16T03:00:09 ERROR(200) ZODB packing
> Traceback (most recent call last):
>   File "/opt/Zope-2.7/lib/python/ZODB/DB.py", line 528, in pack
>     try: self._storage.pack(t,referencesf)
>   File "/opt/Zope-2.7/lib/python/ZODB/FileStorage.py", line 1557, in pack
>     opos = p.pack()
>   File "/opt/Zope-2.7/lib/python/ZODB/fspack.py", line 698, in pack
>     self.gc.findReachable()
>   File "/opt/Zope-2.7/lib/python/ZODB/fspack.py", line 453, in
> findReachable
>     self.buildPackIndex()
>   File "/opt/Zope-2.7/lib/python/ZODB/fspack.py", line 494, in
> buildPackIndex
>     u64(s), th.tlen)
> NameError: global name 's' is not defined
> ------
> 
> .... that seems to be the "stock" code, and nothing has changed that I
> can see. Can anyone offer suggestions on what I might need to do to
> get this back up and packing? Since the database is up to 5.X GB,
> any assistance would be greatly appreciated. :-)

Your database (Data.fs file) has become corrupt.  Packing is trying to
raise CorruptedError via this buggy code:

                self.fail(pos, "redundant transaction length does not "
                          "match initial transaction length: %d != %d",
                          u64(s), th.tlen)

I *think* (but haven't verfied) that if you replace "u64(s)" with
"tlen" it will succeed in raising tthe CorruptedError it's trying to
raise.

In that case packing will still fail, but the message will make more
sense.  It indicates corruption at a very low level.

Next step is to read this:

    http://zope.org/Wikis/ZODB/FileStorageBackup

then start investigating the nature of the damage with fstest.py and fsrefs.py.