Bear R Giles created COMPRESS-513:
-------------------------------------
Summary: [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
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
