The length of some TAR files are not multiples of a fixed block size, and so they seem to end abrubtly in the middle of a block. These files are definitely in error, but do appear to be somewhat common. So common, in fact, that the org.apache.tools.tar.TarBuffer code already attempts to handle these files, but this attempt results in an infinite cycle when reading the last block on certain files, such as the TAR file found within this gzip: http://prdownloads.sourceforge.net/amphetadesk/amphetadesk-src-v0.93.tar.gz The last block is read repeatedly forever as the input buffer is left unclean and the data found earlier is mistakenly parsed as new TAR entries. The following patch fixes this case by zeroing out unread portions of the input buffer when foreshortened input files are encountered: (the same patch can also be found: http://marc.theaimsgroup.com/?l=ant-dev&m=108734434215467&w=2) --- ..\ant-1.6.1\src\main\org\apache\tools\tar\TarBuffer.java 2004-03-09 08:48:00.000000000 -0800 +++ src\org\apache\tools\tar\TarBuffer.java 2004-06-15 16:24:27.992961600 -0700 @@ -25,6 +25,7 @@ import java.io.InputStream; import java.io.OutputStream; import java.io.IOException; +import java.util.Arrays; /** * The TarBuffer class implements the tar archive concept @@ -231,6 +232,19 @@ // Thanks to 'Yohann.Roussel@alcatel.fr' for this fix. // if (numBytes == -1) { + + // However, just leaving the unread portion of the buffer dirty does + // cause problems in some cases. This problem can be seen when + // processing the TAR file found within this GZIP: + // + // http://prdownloads.sourceforge.net/amphetadesk/amphetadesk-src-v0.93.tar.gz + // + // The solution is to fill the unused portion of the buffer with zeros. + // + // - ray@palamida.com + + Arrays.fill(blockBuffer, offset, bytesNeeded, (byte) 0); + break; }
Committed the patch, (with a small fix to the paramters to Arrays.fill()) Thanks for the report and the test file. This will be in the next release of ant.