tar: Only pad partially-filled blocks

[euanh]

Motivation

Tar archives are stored sequences of 512-byte blocks, so archive members must be zero-padded to the nearest whole number of blocks. The current padding calculation incorrectly adds a full 512-byte padding block if the member already finishes on a block boundary.

The tar end of file marker is defined as two consecutive empty blocks:

https://www.loc.gov/preservation/digital/formats/fdd/fdd000531.shtml

However interoperability testing with the system tar binary shows that a single unnecessary empty block will be interpreted as the end of the file.

Modifications

The padding calculation now correctly avoids zero-padding a file which is already a whole number of blocks in length.

Result

• Tar archives produced by the Tar module will match the out put of the system tar utilities.
• This commit will not immediately cause a noticeable change in behaviour because containertool currently only stores one member - the application binary - in an archive.

Test Plan

• New tests check that padding is only applied to partially full blocks.
• All existing tests continue to pass.