[
https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212857#comment-13212857
]
Sebb commented on COMPRESS-16:
------------------------------
The code currently does the following:
{code}
long val = buffer[offset] & 0x7f;
for (int i = 1; i < length; i++) {
// check for val overflow removed here
val = (val << 8) + (buffer[offset + i] & 0xff);
}
{code}
So the lower 7 bits of the first byte are included in the number.
With the current implementation, it is not possible to encode/decode a negative
number.
This is OK for lengths, but would obviously cause a problem for any field that
can be negative.
According to the star doc the time fields can potentially be negative.
Maybe what the star doc means is that certain fields are allowed to contain
negative numbers, in which case the first byte is all ones, but for fields that
are unsigned the lower 7 bits are treated as part of the rest of the number.
In which case, the current parse method is OK so long as it is only used for
unsigned fields.
> unable to extract a TAR file that contains an entry which is 10 GB in size
> --------------------------------------------------------------------------
>
> Key: COMPRESS-16
> URL: https://issues.apache.org/jira/browse/COMPRESS-16
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Environment: I am using win xp sp3, but this should be platform
> independent.
> Reporter: Sam Smith
> Fix For: 1.4
>
> Attachments:
> 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch,
> 0002-Allow-creating-tar-archives-with-files-over-8GB.patch,
> 0004-Prefer-octal-over-binary-size-representation.patch, ant-8GB-tar.patch,
> patch-for-compress.txt
>
>
> I made a TAR file which contains a file entry where the file is 10 GB in size.
> When I attempt to extract the file using TarInputStream, it fails with the
> following stack trace:
> java.io.IOException: unexpected EOF with 24064 bytes unread
> at
> org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348)
> at
> org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388)
> So, TarInputStream does not seem to support large (> 8 GB?) files.
> Here is something else to note: I created that TAR file using TarOutputStream
> , which did not complain when asked to write a 10 GB file into the TAR file,
> so I assume that TarOutputStream has no file size limits? That, or does it
> silently create corrupted TAR files (which would be the worst situation of
> all...)?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
