[Zodb-checkins] CVS: ZODB3 - NEWS.txt:1.33.6.32

[Tim Peters]

Update of /cvs-repository/ZODB3
In directory cvs.zope.org:/tmp/cvs-serv11279

Modified Files:
      Tag: Zope-2_7-branch
	NEWS.txt 
Log Message:
Collector #1379: Undo + FileStorage.restore go BOOM.

FileStorage.__data_find():  When marching across the data records in a
transaction, this had an "off-by-8 error" for data records containing a
backpointer.  The result was reading nonsense bytes as if they were a
data record header, which could lead to an exception (bad argument to
file.seek()), or silent failure to find data that exists.

New test checkRestoreWithMultipleObjectsInUndoRedo provokes two
instances of the bug before the patch.

ZODB 3.3 trunk doesn't have this bug.  ZODB 3.1.5 does have this bug,
but I'm not fixing it at this time.  It's a critical bug for ZRS
(secondaries doing recovery indirectly rely on _data_find); I don't
think base Zope uses FileStorage.restore().


=== ZODB3/NEWS.txt 1.33.6.31 => 1.33.6.32 ===
--- ZODB3/NEWS.txt:1.33.6.31	Fri Jun 18 09:56:33 2004
+++ ZODB3/NEWS.txt	Fri Jun 18 10:37:42 2004
@@ -5,6 +5,15 @@
 Storages
 --------
 
+Collector #1379: Undo + FileStorage.restore.
+In the presence of multiple-object transactions involving undo or
+versions, the FileStorage.restore() method could raise an inappropiate
+exception (bad argument to file.seek()), or silently fail to find
+the data it was looking for.  Base Zope makes no use of restore(), but
+this method is crucial to ZRS recovery, so this is a critical bugfix
+at least for sites running ZRS.  Thanks to Tres Seaver and Jim Fulton
+for the diagnosis and cure.
+
 As announced with 3.2.2b1, the Berkeley-based storages are no longer
 supported.  The code for them still exists, but the Berkeley tests have
 been disabled (primarily to prevent segfaults on Linux systems with