ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39924] New: - TarInputStream.read() never returns EOF
Date Wed, 28 Jun 2006 19:10:23 GMT
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: phulst@sbcglobal.net


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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message