DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39924>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39924 Summary: TarInputStream.read() never returns EOF Product: Ant Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: dev@ant.apache.org ReportedBy: [EMAIL PROTECTED] This is an issue with org.apache.tools.tar.TarBuffer When trying to use the TarInputStream with a corrupted archive the number of bytes passing through the stream is whatever value is set for the filesize in the tar header, and not the actual number of bytes in the tar file. The TarBuffer.readBlock() method will read a number of bytes (a given blocksize) from the stream. A previous fix (#29877) changed the functionality in such a way that if EOF is read before the entire block is filled, then the remaining part of the block buffer is filled with 0s. The problem is that this is also done when no bytes at all could be read from the stream. As a result, TarInputStream.read will never return EOF anymore, and will just fill up your buffer with zeros whenever you try to read from the stream. None of this is a real issue when the header of the tar archive indicates the correct size of the data. But if for any reason the size field in the tar header contains a huge number your application and/or any wrapped streams potentially end up having to process gigabytes of zeros. My suggested fix is simple: when EOF is read, - if any bytes were read, fill the buffer with 0s up to the block size, as before - if no bytes has been read yet, return false simply add the following "if(offset == 0) return false" as below. ... if (numBytes == -1) { // if no bytes had been read at all yet, return false if (offset == 0) return false; // However, just leaving ...... ..... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]