[tahoe-lafs-trac-stream] [tahoe-lafs] #2035: Publishing the same immutable content when some shares are unrecoverable does not repair that content.

[tahoe-lafs]

#2035: Publishing the same immutable content when some shares are unrecoverable
does not repair that content.
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  daira
  nejucomo               |     Status:  new
         Type:  defect   |  Milestone:  undecided
     Priority:  normal   |    Version:  1.10.0
    Component:  unknown  |   Keywords:  preservation, reliability, servers-
   Resolution:           |  of-happiness,upload, repair, tahoe-backup
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by nejucomo):

 Replying to [comment:4 nejucomo]:
 > More IRC from nejucomo (me):
 >
 >     Ah!  I have a hypothesis: The backup command keeps a local cache of
 which file revisions have been uploaded.  Then it checks that as an
 optimization.  If you can find that cache db, try renaming it, then rerun
 the backup.

 `srl` verified that removing `backupdb.sqlite`, deleting the backup
 directories, and then rerunning backup successfully stored their data into
 the same immutable caps.

 Therefore I propose this is a bug in backupdb caching logic.  If possible
 it should verify the health of items in the cache.  If this is expensive,
 maybe it could be an opt-in behavior with a commandline option.

 I'm going to update the keywords to reflect this new information.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2035#comment:5>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage