On 21/11/2023 21:05, Xudong Yang wrote:
java -jar commons-compress-1.25.0.jar ruff-aarch64-apple-darwin.tar
Exception in thread "main" java.io.IOException: Truncated TAR archive
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.read(TarArchiveInputStream.java:694)
at
org.apache.commons.compress.utils.IOUtils.readFully(IOUtils.java:244)
at org.apache.commons.compress.utils.IOUtils.skip(IOUtils.java:355)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:451)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:426)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:50)
at
org.apache.commons.compress.archivers.Lister.listStream(Lister.java:79)
at org.apache.commons.compress.archivers.Lister.main(Lister.java:133)
I had a quick look at this. Some observations:
1. When using listZipUsingTarFile(file) in Lister instead of
listStream(file, args), there is no exception.
2. The stacktrace suggests that IOUtils.skip() is being called, but I
suspect skip() isn't aware of the sparseness of the file.
TarArchiveInputStream.java contains a skip method which *is* aware of
sparseness.
3. The sparse file is the first and only entry in the tar file. There
don't seem to be any test cases that cover that particular scenario,
presumably, the skip() behaviour results in the TarArchiveInputStream
thinking that there's another entry, which there isn't.
I don't suppose anyone has been able to construct a smaller file that
also fails? The ruff example is probably too large to include with the
test cases, and its license is unclear to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
