[jira] [Commented] (COMPRESS-513) [Tar] error decoding sparse file header

[Bear R Giles (Jira)]

    [ 
https://issues.apache.org/jira/browse/COMPRESS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099951#comment-17099951
 ] 

Bear R Giles commented on COMPRESS-513:
---------------------------------------

I just noticed that the 'environment' made it hard to see to see the script 
that created this tar file. It might have a clue if it's an unexpected 
configuration.

{code:bash}
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}


> [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)