>> > With all of the patch except for the change in the initial
>>  > initialization of name-end, the results look correct, except the
>>  > penultimate line ends in "foo2" instead of "foo20"; that is because
>>  > the name field here fill the entire field with no nulls, but the code
>>  > previously assumed there would be at least one null.  (It's possible
>>  > that similar adjustments are required for the initial values of
>>  > link-end, gname-end, and uname-end.)
>>
>>  Does your patch also handle @LongLink currently unsupported by tar-mode.el?
>
> Is it actually unsupported?  When I tried to make a tarball to test
> this issue with GNU tar, I saw stuff about "@LongLink" when I opened
> it in tar-mode.  (Try making a tarball from the one I sent using GNU
> tar; you'll see what I mean; I made my test tarball with pax, since
> that was what was used to make the one I opened when I first noticed
> this issue.)  I don't know if it was correct or not, though.

Please see a test tarball attached below.  It is correctly created with
GNU tar, but opening it in Emacs displays the following message:

    Warning: premature EOF parsing tar file

Also its file listing is incomplete, file names are truncated, and content
of some files is inserted into the file listing in the tar-mode buffer.

I thought your patch will fix these problems.