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

New Issue

tahoe-lafs · 2011-04-09T20:20:02Z

davidsarah commented

2011-04-09 20:20:02 +00:00

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 source:src/allmydata/test/test_mutable.py (for no-network tests) and/or source:src/allmydata/test/test_system.py (for full system tests).

tahoe-lafs added the

labels 2011-04-09 20:20:02 +00:00

tahoe-lafs added this to the soon milestone 2011-04-09 20:20:02 +00:00

Brian Warner <warner@lothar.com> commented

2011-08-27 22:51:05 +00:00

In changeset: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.

In changeset: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. ```