Overview
Artifact ID: | db3f0b706dc7a51b28ae8701f2257f962288603bb8031ec4068752f0c8ab1f10 |
---|---|
Ticket: | b01462dff791ba84ecf444d01281412d781bdfbb
untar: expected integer but got a list |
User & Date: | aku 2025-01-13 21:05:35 |
Changes
- icomment:
@ 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.
- login: "aku"
- mimetype: "text/x-markdown"