[
https://issues.apache.org/jira/browse/COMPRESS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101615#comment-17101615
]
Peter Lee commented on COMPRESS-513:
------------------------------------
{code:java}
– TarArchiveStructSparse
offset: 0, numbytes: 16384
offset: 24576, numbytes: 12288
offset: 40960, numbytes: 12288
offset: 57344, numbytes: 12288
offset: 4202496, numbytes: 0{code}
Is this the sparse map of the tarball file? Seems the sparse offsets and
numbytes are not that big.
If this is not the sparse map of your tarball archive, could you provide some
detailed sparse map?
I'm almost sure that this tarball with sparse has a big sparse map that Commons
Compress can not handle now, but I need some more info to make it sure.
It will be much more helpful if you could show me the value of the variable
'BigInteger val', by adding a breakpoint in TarUtils.parseBinaryBigInteger :
{code:java}
private static long parseBinaryBigInteger(final byte[] buffer,
final int offset,
final int length,
final boolean negative) {
final byte[] remainder = new byte[length - 1];
System.arraycopy(buffer, offset + 1, remainder, 0, length - 1);
// evalute the value of the variable 'val'
BigInteger val = new BigInteger(remainder);
if (negative) {
// 2's complement
val = val.add(BigInteger.valueOf(-1)).not();
}
if (val.bitLength() > 63) {
throw new IllegalArgumentException("At offset " + offset + ", "
+ length + " byte binary number"
+ " exceeds maximum signed long"
+ " value");
}
return negative ? -val.longValue() : val.longValue();
}
{code}
Or maybe you can test with this snapshot version of Commons Compress with more
detailed infomation :
[https://github.com/PeterAlfredLee/commons-compress/tree/COMPRESS-513]
> [Tar] error decoding sparse file header
> ---------------------------------------
>
> Key: COMPRESS-513
> URL: https://issues.apache.org/jira/browse/COMPRESS-513
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.20
> Environment: # Ubuntu 19.10.
> #
> # Gnu tar 1.30
> Reporter: Bear R Giles
> Priority: Major
>
> I am seeing an IllegalArgumentException when attempting to scan a (gnu) tar
> file containing a backup of my home directory. -The entry is a sqlite
> database table used by chromium.-
> The archive file is 62 GB and over 1 million files. ( ! ) (Can you tell I'm a
> developer?)
> The error is:
> {noformat}
> java.lang.IllegalArgumentException: At offset 0, 12 byte binary number
> exceeds maximum signed long value
> java.lang.IllegalArgumentException: At offset 0, 12 byte binary number
> exceeds maximum signed long value
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseBinaryBigInteger(TarUtils.java:231){noformat}
> From instrumenting the code I can determine that the TarArchiveEntry reports:
> * name:
> ./snap/chromium/1005/.config/chromium/Default/Storage/ext/jajcoljhdglkjpfefjkgiohbhnkkmipm/def/GPUCache/data_3
> * mode: 0600
> * size: 53248
> * real: 4202496
> The (presumed) sparse headers are:
> {noformat}
> c3 ca 04 c1 00 00 02 00 03 00 00 00 |
> 00 10 00 00 04 00 00 00 00 04 00 00 |
> 03 00 00 00 01 00 00 00 00 00 00 00 |
> fc 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 73 77 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00 |
> 00 00 00 00 00 00 00 00 00 00 00 00
> {noformat}
> And for this specific entry
> * buffer: c3 ca 04 c1 00 00 02 00 03 00 00 00
> * remainder: ca 04 c1 00 00 02 00 03 00 00 00
> * neg: false
> * value: -65259544571650071836229632
> I'll add the full header in a comment later today. It looks likely that the
> header format isn't properly recognized.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
