Tcl Library Source Code

My thought that this was an encoding issue was wrong. The iso8859-1 encoding used by Tcl 9 is correct.

The issue is indeed one of octal conversion, and Ashok's change is a fix.

Basically, using pre-patch set x [format %d 0[string trim [set $x] " \x00"]] mis-converts the size information found in the first header.

With the size wrong the code looks at the wrong place in the file for the next header, reads bogus data, and then chokes on that.

With the patch applied (set x [format %d 0o0[string trim [set $x] " \x00"]]) the conversion to decimal is done correctly, and the next header is read and processed ok, and so on, to the end of the tar file.

Using the cantrbry.tar file the code reads

	|size|	|00000451031|

and mis-converts to

	|size|	|451031|DECIMAL

No conversion was done at all. With the path on the other hand we get

	|size|	|152089|DECIMAL

which is correct.

And with that I have confirmed the issue, understood the issue, confirmed and understood the fix, and can now extend the testsuite.

Thank you for that reference.

Will use that to continue my investigation this evening.

... Could not resist, tried already a bit ...

Looks to be more of an channel encoding issue.

The 8.5 reports that the channel is set to lf binary (translation & encoding). The 9.0 seems to use lf iso8859-1 instead, and that causes the following read to return something bonkers, and the uid handling chokes on it.

Will have to look into the internal SetupReading helper what is going on.

But this really has to be deferred to the evening.

I just tested using the following file

https://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz

from here:

https://corpus.canterbury.ac.nz/descriptions/

Just ungziped it and then tried to untar using the tcl script.

Here is the error I get this time:

expected integer but got "0à♥♥☻"
    while executing
"format %d 0[string trim [set $x] " \x00"]"
    (procedure "readHeader" line 8)
    invoked from within
"readHeader [read $fh 512]"
    (procedure "::tar::untar" line 22)
    invoked from within
"::tar::untar untar-test.tar"
    (file "untar-test.tcl" line 3)

untar was able to extract the first file and then failed

@ apnadkarni

Do you have a small test case we could add to the test suite of tar for this ?

I have trouble reproducing the issue (before applying your patch).

The only time I managed to get something similar was when the tar file contained a symbolic link I had in my tcllib checkout.

... And that failure was with 8.5, and ok for 9.0. ... After applying your (apn's) patch the failure (see below) appears for tcl 9 as well.

Ok. After some rummaging around my failure is actually a known limitation of the tar package. My tarball contained a type K long symbolic link, and that is not supported.

Removing these symlinks from my checkout and the tarballs I create with the local GNU tar 1.30 are ok, before and after the applying the patch. So not usable for reproduction, nor as testcase.

Is it possible to make one of the failing tarballs available ?

I do not have PeaZip.

Proposed fix in bug-b01462dff7