how to fix 'multiple versions are recoverable'?

[humberto]

I have a couple of directories that are

Not Healthy! : Unhealthy: multiple versions are recoverable

• Report:

Recoverable Versions: 6*seq24-wgxp/10*seq26-4tdb Unhealthy: there are multiple recoverable versions Best Recoverable Version: seq26-4tdb

I can't see how to fix this. A deep check with the repair checkbox leaves the directories in the same state.

A simple check with the repair checkbox shows me the versions available, but I didn't see how to fix the directory.

[humberto]

Zooko sent a list of related tickets:

Here are all the tickets that look vaguely related to the topic of "robust upload/download of mutables":

​http://allmydata.org/trac/tahoe-lafs/ticket/232# Peer selection doesn't rebalance shares on overwrite of mutable file. ​http://allmydata.org/trac/tahoe-lafs/ticket/474# uncaught exception in mutable-retrieve: UCW between mapupdate and retrieve ​http://allmydata.org/trac/tahoe-lafs/ticket/540# inappropriate "uncoordinated write error" after handling a server failure ​http://allmydata.org/trac/tahoe-lafs/ticket/541# foolscap 'reference'-token bug workaround in mutable publish ​http://allmydata.org/trac/tahoe-lafs/ticket/546# mutable-file surprise shares raise inappropriate UCWE ​http://allmydata.org/trac/tahoe-lafs/ticket/547# mapupdate(MODE_WRITE) triggers on a false boundary ​http://allmydata.org/trac/tahoe-lafs/ticket/548# mutable publish sends queries to servers that have already been asked ​http://allmydata.org/trac/tahoe-lafs/ticket/549# MODE_WRITE mapupdate: maybe increase epsilon to handle large batches of new servers better ​http://allmydata.org/trac/tahoe-lafs/ticket/846# allmydata.test.test_system.SystemTest?.test_mutable sometimes hangs on a slow machine ​http://allmydata.org/trac/tahoe-lafs/ticket/893# UCWE when mapupdate gives up too early, then server errors require replacement servers

[davidsarah]

Reformatting the list in Humberto's comment:

• #232 Peer selection doesn't rebalance shares on overwrite of mutable file
• #474 uncaught exception in mutable-retrieve: UCW between mapupdate and retrieve
• #540 inappropriate "uncoordinated write error" after handling a server failure
• #541 foolscap 'reference'-token bug workaround in mutable publish
• #546 mutable-file surprise shares raise inappropriate UCWE
• #547 mapupdate(MODE_WRITE) triggers on a false boundary
• #548 mutable publish sends queries to servers that have already been asked
• #549 MODE_WRITE mapupdate: maybe increase epsilon to handle large batches of new servers better
• #846 allmydata.test.test_system.SystemTest.test_mutable sometimes hangs on a slow machine
• #893 UCWE when mapupdate gives up too early, then server errors require replacement servers

[zooko]

It's really bothering me that mutable file upload and download behavior is so finicky, buggy, inefficient, hard to understand, different from immutable file upload and download behavior, etc. So I'm putting a bunch of tickets into the "1.8" Milestone. I am not, however, at this time, volunteering to work on these tickets, so it might be a mistake to put them into the 1.8 Milestone, but I really hope that someone else will volunteer or that I will decide to do it myself. :-)

[daira]

Proposed behaviour: mutable repair should delete (by setting the container to zero length) shares of previous versions, after confirming that the current version meets the happiness threshold. See also #614, #1057 and #2060.

[zooko]

Replying to daira:

Proposed behaviour: mutable repair should delete (by setting the container to zero length) shares of previous versions, after confirming that the current version meets the happiness threshold.

Sounds good to me!

[PRabahy]

I hit this under slightly different circumstances.

C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\bin>tahoe deep-check --repair CryptoResearch?: ERROR: MustForceRepairError?(There were unrecoverable newer versions, so force=Tr ue must be passed to the repair() operation) "[Failure instance: Traceback: <class 'allmydata.mutable.repairer.MustForceRepai? rError'>: There were unrecoverable newer versions, so force=True must be passed to the repair() operation" C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\base.py:793:runUntilCurrent C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\fool scap-0.6.4-py2.7.egg\foolscap\eventual.py:26:_turn C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:361:callback C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:455:_startRunCallbacks --- <exception caught here> --- C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twis ted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:542:_runCallbacks c:\users\prabahy\downloads\allmydata-tahoe-1.10.0\src\allmydata\mutable\repairer .py:83:_got_full_servermap

Edit: Ouch, sorry about the formatting, but all the details are there.

[zooko]

Thanks for the bug report, PRabahy! Here's an attempt to untangle the formatting:

C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\bin>tahoe deep-check --repair CryptoResearch:
ERROR: MustForceRepairError(There were unrecoverable newer versions, so force=True must be passed to the repair() operation)
"[Failure instance: Traceback: <class 'allmydata.mutable.repairer.MustForceRepairError'>: There were unrecoverable newer versions, so force=True must be passed to the repair() operation"
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\base.py:793:runUntilCurrent
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\foolscap-0.6.4-py2.7.egg\foolscap\eventual.py:26:_turn
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:361:callback
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:455:_startRunCallbacks
--- <exception caught here> ---
C:\Users\PRabahy\Downloads\allmydata-tahoe-1.10.0\support\Lib\site-packages\twisted-11.0.0-py2.7-win32.egg\twisted\internet\defer.py:542:_runCallbacks
c:\users\prabahy\downloads\allmydata-tahoe-1.10.0\src\allmydata\mutable\repairer.py:83:_got_full_servermap

[daira]

Replying to PRabahy:

I hit this under slightly different circumstances. [...]

I think that is probably a different bug -- filed as #2109.

[warner]

Milestone renamed

[warner]

renaming milestone

[exarkun]

Moving open issues out of closed milestones.

[meejah]

Ticket retargeted after milestone closed