shares should have a layout version number in them

[warner]

having a version number in the shares would make it easier to preserve share data across layout changes in the future.

[zooko]

Good idea!

[zooko]

This is part of the "long-term data reliability" task. I would like to see this ticket done for v0.6.

[warner]

Partially done, in 94233b88134e9a00. The first four bytes of the file on disk are a version number for the benefit of the StorageServer?: v=1 indicates that the lease information is stored immediately following the share data. The actual format is:

• four bytes sharefile version number
• four bytes share data length
• four bytes number-of-leases
• share data
• leases

To complete this ticket, the share data itself needs to share with a version number, for the benefit of the client (rather than the StorageServer?). The client only gets to see the share data, not the leases, and there is further structure inside the share data, so that needs its own version number as well.

[warner]

Completed, in 76be4a582c3487ea. The first four bytes of the share data (which is stored inside the share file) now have a version number as well. v=1 indicates the following layout:

0x00: version number (=00 00 00 01)
0x04: segment size
0x08: data size
0x0c: offset of data (=00 00 00 24)
0x10: offset of plaintext_hash_tree
0x14: offset of crypttext_hash_tree
0x18: offset of block_hashes
0x1c: offset of share_hashes
0x20: offset of uri_extension_length + uri_extension
0x24: start of data
?   : start of plaintext_hash_tree
?   : start of crypttext_hash_tree
?   : start of block_hashes
?   : start of share_hashes
       each share_hash is written as a two-byte (big-endian) hashnum
       followed by the 32-byte SHA-256 hash. We only store the hashes
       necessary to validate the share hash root
?   : start of uri_extension_length (four-byte big-endian value)
?   : start of uri_extension