You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments