if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients

[davidsarah]

When a storage server receives a remote_get_buckets or remote_slot_testv_and_readv_and_writev request, it will try to create share objects for each of the shares it stores under that SI that are wanted by the client. If any of those shares have a corrupt header (typically resulting in a UnknownMutableContainerVersionError, UnknownImmutableContainerVersionError, or struct.error from the share class constructor), the whole request will fail, even though the server might hold other shares that are not corrupted.

Unfortunately there is no way in the current storage protocol to report success for some shares and a failure for others. The options are:

• the status quo -- no shares in the shareset are accessible;
• shares with corrupt headers are ignored on read requests;
• if all shares are corrupted then report one of the errors, but if only some shares in a shareset have corrupted headers, ignore them and allow access to the rest.

I found this bug when working on the branch for #999, but I think it also applies to trunk.

[davidsarah]

[posted description as a comment by mistake]

[davidsarah]

I will write a test.