Opened at 2011-04-09T20:20:02Z

Last modified at 2011-08-27T22:51:05Z

#1390 new defect

test whether it works to change encoding parameters for a new version of a mutable file

Reported by: davidsarah Owned by:
Priority: major Milestone: soon
Component: code-encoding Version: 1.8.2
Keywords: test mutable Cc:
Launchpad Bug:

Description (last modified by davidsarah)

We don't appear to have unit tests for the case where different versions of a mutable file have different encoding parameters. The natural place for such tests to go would be src/allmydata/test/test_mutable.py (for no-network tests) and/or src/allmydata/test/test_system.py​ (for full system tests).

Change History (2)

comment:1 Changed at 2011-04-09T22:10:47Z by davidsarah

  • Description modified (diff)

comment:2 Changed at 2011-08-27T22:51:05Z by Brian Warner <warner@…>

In 370e6f271e40945b:

SDMF: update filenode with correct k/N after Retrieve. Fixes #1510.

Without this, we get a regression when modifying a mutable file that was
created with more shares (larger N) than our current tahoe.cfg . The
modification attempt creates new versions of the (0,1,..,newN-1) shares, but
leaves the old versions of the (newN,..,oldN-1) shares alone (and throws a
assertion error in SDMFSlotWriteProxy.finish_publishing in the process).

The mixed versions that result (some shares with e.g. N=10, some with N=20,
such that both versions are recoverable) cause problems for the Publish code,
even before MDMF landed. Might be related to refs #1390 and refs #1042.

Note: See TracTickets for help on using tickets.