That would eliminate the need for the flipping step at the end of (non-memory-mapped) encoding. It could allow efficient appends to an encoded file.
Downsides:
4 KB space overhead in front of short files.
Decoding short files would require reading past 4 KB of garbage data.
Write failures (e.g. power loss) could result in a corrupted file, where some interior hashes have been updated but not others.
Best alternative: Use an outboard tree, which you incrementally update (not currently implemented). When you need extra space at the front of the tree, just rewrite the whole thing. The overhead will be small relative to all the appending that's happening to the raw output file.
Correction: It's not enough to just have space for parents at the front. You also need space for parents in front of every partial tree along the right edge. (Not 64, but some smaller number corresponding to the maximum size of that subtree.) So this sort of design is actually fairly involved, and not just a tweak to header parsing.
That would eliminate the need for the flipping step at the end of (non-memory-mapped) encoding. It could allow efficient appends to an encoded file.
Downsides:
Best alternative: Use an outboard tree, which you incrementally update (not currently implemented). When you need extra space at the front of the tree, just rewrite the whole thing. The overhead will be small relative to all the appending that's happening to the raw output file.
Correction: It's not enough to just have space for parents at the front. You also need space for parents in front of every partial tree along the right edge. (Not 64, but some smaller number corresponding to the maximum size of that subtree.) So this sort of design is actually fairly involved, and not just a tweak to header parsing.