[
https://issues.apache.org/jira/browse/COMPRESS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bear R Giles updated COMPRESS-513:
----------------------------------
Description:
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.
was:
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:
{code:java}
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){code}
>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:
{code:java}
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
{code}
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.
> [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
> File generated with
>
> {code:java}
> PREFIX=/media/backups/monthly/users
> SYSTEM=`uname -n`
> TS=`/bin/date +%Y-%m-%d`
> for USER in bgiles
> do
> DIR=${PREFIX}/${USER}/home/${TS}
> /usr/bin/install -d ${DIR}
> LABEL=home-${USER}-${SYSTEM}-${TS}
> BASENAME=${DIR}/${LABEL}
> /bin/tar czvf ${BASENAME}.tar.gz \
> --index-file ${BASENAME}.idx \
> --exclude-tag=NOARCHIVE.TAG \
> --exclude-caches-all \
> --preserve-permissions \
> --sparse \
> --label=${LABEL} \
> --one-file-system \
> --directory /home/${USER} .
> /bin/gzip ${BASENAME}.idx
> # change ownership
> /bin/chown -R backup:backup ${DIR}
> /bin/chmod -R o-rwx ${DIR}
> /bin/chmod -R o-rwx,a-w ${DIR}/*
> done
> {code}
>
>
> 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)
