[
https://issues.apache.org/jira/browse/COMPRESS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101214#comment-17101214
]
Bear R Giles commented on COMPRESS-513:
---------------------------------------
It's a 10 GB file.
The information I included above re the PAX header seems to be correct. At
least least the final number sparse list matches the size of the file using `ls
-l`. I could write a small app to double-check the holes but I haven't really
done anything with the libext4 in years.
Fortunately it should be easy-ish to recreate. Chrome/chromium produces a lot
of sparse files in its caches. I can read the prior backup so what I think
happened was that this file got bumped and naturally the newly allocated space
will be mostly hole unless they explicitly rebalanced the contents of the file.
You could try creating a tar file of your chrome cache (.cache/chromium or
snap/chromium) or just create a sparse file with only data in the locations
identified in the header.
{noformat}
– TarArchiveStructSparse
offset: 0, numbytes: 16384
offset: 24576, numbytes: 12288
offset: 40960, numbytes: 12288
offset: 57344, numbytes: 12288
offset: 4202496, numbytes: 0{noformat}
I'll attach the full stack later. I'm still working and my app takes about 30
minutes to get to where it crashes since it processes the January backup before
the February backup AND this file seems to be relatively late in the backup
file.
> [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)
