[ZODB-Dev] RE: Corrupt db when trying to pack

[Tim Peters]

[Gerry Kirk]
> Makes sense, I think. In my case, I would think the corruption is
> somewhere in the middle of the file, so I would need to extract that part
> out and merge the front and end parts together.

You can't remove data "from the middle" of a FileStorage and expect anything
to work afterwards.  Only a pack operation can remove interior bytes
successfully, and as the link referenced before said, packing is in no way
an error recovery procedure.  Packing can be a damage magnifier.

> Yes, but my point is, I'm not detecting damage now, so maybe there is
> nothing to repair.

Good -- then let's stop trying to fix it <wink>.

> I tried running a pack on a copy of a backup, and got this error:
>
> Traceback (innermost last):
>   Module ZPublisher.Publish, line 100, in publish
>   Module ZPublisher.mapply, line 88, in mapply
>   Module ZPublisher.Publish, line 40, in call_object
>   Module App.ApplicationManager, line 428, in manage_pack
>   Module ZODB.DB, line 528, in pack
>   Module ZODB.FileStorage, line 1557, in pack
>   Module ZODB.fspack, line 709, in pack
>   Module ZODB.fspack, line 754, in copyToPacktime
>   Module ZODB.fspack, line 80, in _read_num
> IOError: [Errno 22] Invalid argument
>
> Googling didn't track down what this problem is.

Doesn't mean anything to me either.  The news file for ZODB 3.2.2:

    http://zope.org/Products/ZODB3.2/NEWS

mentions a bad argument to file.seek() (which is what your IOError is) in
the context of Collector issue #1379, but that shouldn't be relevant to
packing.  I know of no other report like yours.  Did this copy of a backup
pass fstest and fsrefs before the pack attempt?  If it did not, then this is
likely just garbage-in, garbage-out.  If it did pass, then maybe issue #1379
is relevant in a way I don't know about, and upgrading to ZODB 3.2.3 would
repair the problem.

> Thanks for all your help so far, Tim! I really appreciate it.

You're welcome!