[tahoe-lafs-trac-stream] [tahoe-lafs] #1566: if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients

[tahoe-lafs]

#1566: if a stored share has a corrupt header, other shares held by that server
for the file should still be accessible to clients
-----------------------------+---------------------------------------------
     Reporter:  davidsarah   |      Owner:  davidsarah
         Type:  defect       |     Status:  assigned
     Priority:  major        |  Milestone:  undecided
    Component:  code-        |    Version:  1.9.0b1
  storage                    |   Keywords:  corruption preservation storage
   Resolution:               |
Launchpad Bug:               |
-----------------------------+---------------------------------------------

Comment (by warner):

 I think the server should not report anything to the client about shares
 with corrupt headers. It should file a local corruption report (as if the
 remote client had called {{{remote_advise_corrupt_share()}}}, but with a
 flag that shows this was discovered locally, and probably in a part of the
 share that the client wouldn't be able to read anyways).

 I'd be ok with reporting "nope, no shares here" if all shares are corrupt,
 rather than returning an error. I don't think the client is in a good
 position to do much with information about shares that are so corrupt that
 it can't even see part of their contents (which is what header corruption
 would mean). The only interaction I can think of is how the client might
 try to repair this file: they can't replace the corrupt-header share (the
 server admin will need to delete it locally), they can't modify it's
 contents, so they ought to just put a new copy somewhere else. They'll
 probably try to put a new copy on this server, which it needs to refuse
 (refusal doesn't always mean no-space-available, although the client might
 have bugs which makes it interpret refusal that way).

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566#comment:3>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage