From: Brian Warner <warner@allmydata.com>
Date: Tue, 25 Nov 2008 21:27:35 +0000 (-0700)
Subject: mutable publish: reinstate the foolscap-reference-token-bug workaround, both for... 
X-Git-Url: https://git.rkrishnan.org/components/com_hotproperty/flags/somewhere?a=commitdiff_plain;h=7ea0a1316a391402b46e020adea03317735b2853;p=tahoe-lafs%2Ftahoe-lafs.git

mutable publish: reinstate the foolscap-reference-token-bug workaround, both for the original reasons and because of an apparent new foolscap bug that's triggered by reference tokens. See #541 for details.
---

diff --git a/src/allmydata/mutable/publish.py b/src/allmydata/mutable/publish.py
index 801d2180..59460c4f 100644
--- a/src/allmydata/mutable/publish.py
+++ b/src/allmydata/mutable/publish.py
@@ -577,7 +577,27 @@ class Publish:
 
             else:
                 # add a testv that requires the share not exist
-                testv = (0, 1, 'eq', "")
+
+                # Unfortunately, foolscap-0.2.5 has a bug in the way inbound
+                # constraints are handled. If the same object is referenced
+                # multiple times inside the arguments, foolscap emits a
+                # 'reference' token instead of a distinct copy of the
+                # argument. The bug is that these 'reference' tokens are not
+                # accepted by the inbound constraint code. To work around
+                # this, we need to prevent python from interning the
+                # (constant) tuple, by creating a new copy of this vector
+                # each time.
+
+                # This bug is fixed in foolscap-0.2.6, and even though this
+                # version of Tahoe requires foolscap-0.3.1 or newer, we are
+                # supposed to be able to interoperate with older versions of
+                # Tahoe which are allowed to use older versions of foolscap,
+                # including foolscap-0.2.5 . In addition, I've seen other
+                # foolscap problems triggered by 'reference' tokens (see #541
+                # for details). So we must keep this workaround in place.
+
+                #testv = (0, 1, 'eq', "")
+                testv = tuple([0, 1, 'eq', ""])
 
             testvs = [testv]
             # the write vector is simply the share