From: Brian Warner 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/architecture.txt?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