[ZODB-Dev] RE: Corrupt db when trying to pack
Tim Peters
tim at zope.com
Mon Oct 4 15:25:07 EDT 2004
[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!
More information about the ZODB-Dev
mailing list