You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by bu...@apache.org on 2006/06/28 21:10:23 UTC
DO NOT REPLY [Bug 39924] New: - TarInputStream.read() never returns EOF
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
DO NOT REPLY [Bug 39924] - TarInputStream.read() never returns EOF
Posted by bu...@apache.org.
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
peterreilly@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|--- |1.7
------- Additional Comments From peterreilly@apache.org 2006-09-09 21:45 -------
Fixed in SVN, thanks for the report.
--
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