[Toybox] tar tests.

[Rob Landley]

On 3/14/19 1:00 PM, Rob Landley wrote:
> On 3/14/19 12:08 AM, enh wrote:
>> On Wed, Mar 13, 2019 at 4:05 PM Rob Landley <rob at landley.net> wrote:
>>
>> ((speaking of which, some of the tar tests are failing now.))
> 
> I usually consider "consumes its own output" to be "necessary but not
> sufficient" as tests go: if it makes the same mistake at each end, we won't
> catch it. So during development I've been testing that it can extract and
> reproduce the linux-4.20.tar.gz tarball.

The next reason these are bad tests is they're not orthogonal. The first test is
testing 37 things so if it doesn't work you have no idea why, and a single
failure (in this case autodetection of decompression type when you didn't
specify) makes pretty much all the tests fail.

The autodetect issue is because if you "gzip blah.tar | tar xv" it won't
autodetect because the input isn't seekable. It's silly to have stdin an a file
treated differenty, but the implementation details of treating them the same are
a bit funky because it reads the first tar record, and if it's not "ustar" it
checks for bz2 and gz signatures, and... then what? You can fork a bzip2 or gzip
process to inherit the filehandle but can't stick the 512 bytes of data BACK
into it.

On a seekable filehandle it seeks back before handing it over to the new
process. On a nonseekable filehandle you have to fork a gratuitous process to
cat the two input streams together. (It can sendfile() the second part but it's
still there being a process until EOF. To do it gracefully I need a pipe unget
ioctl, bug all I can find is messages on linux-kernel that say "oh wouldn't that
be nice" and then not implementing it. I can do it with a tty, ioctl(TIOCSTI)
albeit a byte at a time, but it's doable. But not for _pipes_ that I can find...)

Anyway, that's why that part's not in this checkin yet. :)

Rob