[the mail didn't make it through, I assume due to the attachment. Resending without attachment.]
Hi all, I thought it impossible for such a venerable tool, but... there's a bug in tar, specifically multi-volume mode, GNU format: If the previous volume ends on a file boundary, i.e. the first thing in the next volume would be the next file's header, a "M" header is output with the next file's size - which is 512 too short because the next thing is the next file's tar header, which in fact has the same size value. The correct thing would be either not outputting an "M" header at all, (better in terms of compatibility), or outputting the "M" header with the size adjusted for the upcoming tar header. The behavior is still in the current git HEAD, 505cf47a0af0 as of my testing. I've attached a reproducer script. In case it gets mangled/dropped, there's a copy as a github gist: https://gist.github.com/eqvinox/71d951f2f47a06c1b3d1c532e4605d5d I did try to find/fix it, but the code is a little... byzantine? Cheers, -equi P.S.: I also tried pax mode, ... I don't quite understand the result of that (yet), with the ./GNUFileParts/PaxHeaders and all.
