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.