[tahoe-lafs-trac-stream] [Tahoe-LAFS] #755: Allow deep-check to continue after error, and: if there is an unrecoverable subdirectory, the deep-check report (both WUI and CLI) loses other information

[Tahoe-LAFS]

#755: Allow deep-check to continue after error, and: if there is an unrecoverable
subdirectory, the deep-check report (both WUI and CLI) loses other
information
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:  daira
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  soon
  critical               |
    Component:  code-    |    Version:  1.4.1
  dirnodes               |   Keywords:  usability error tahoe-check wui
   Resolution:           |  verify repair
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by daira):

 * cc: kyle@… (added)
 * owner:  davidsarah => daira
 * status:  assigned => new


Comment:

 Kyle Markley wrote on tahoe-dev:
 > When `tahoe deep-check --repair` encounters a file it can't repair, it
 stops without reporting anything about what file gave it trouble.
 > What do I do about this?  I rerun, this time with `-v`, so I get a
 listing of what files it is working on.  From that list I can often infer
 which file had the error.  Assuming I still have the original file, the
 corrective action is to tahoe put the file.  Then I can restart the deep-
 check.
 > But in a directory tree with thousands of files, that takes forever!
 Instead, I can restart the deep-check in a subdirectory closer to the
 previous failure.  But this is a lot of tedious work.
 >
 > I wish that `tahoe deep-check` would:
 >
 > 1. Report which file is unrepairable.
 > 2. Not stop at the first error, but continue and report all errors upon
 completion.
 >
 > When an unrepairable file is an immutable directory, what corrective
 action should be taken?  I have resorted to modifying the directory by
 creating an empty file, performing a `tahoe backup`, and then continuing
 the `deep-check --repair`.  But I cannot then remove the empty file,
 because that would cause the next backup to point to the original
 (unrepaired) directory.  Can this be improved?
 >
 > I wish that `tahoe backup` could be combined with `tahoe deep-check
 --repair`.  The behavior would be like deep-check, but if any file is
 unrepairable yet exists in in the local filesystem at the corresponding
 path, upload it.  And for bonus points this should guarantee happiness,
 not just healthiness.  Or, it would be almost as good if deep-check would
 update the backup database so the next invocation of tahoe backup would
 re-upload the appropriate files and directories.
 >
 > Essentially, I struggle with the fact that "`tahoe backup`" completes
 successfully without guaranteeing the recoverability of files it claims to
 have backed up.  The backup database is out-of-sync with the healthiness
 of files on the grid, and there is no way to bring them in-sync.  Sure, I
 can delete the backup database, but I don't want to pointlessly re-upload
 all the healthy files.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/755#comment:37>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage