[ 
https://issues.apache.org/jira/browse/COMPRESS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved COMPRESS-337.
-------------------------------------
    Resolution: Won't Fix

actually "can't fix". Somebody seems to be creating invalid archives and 
neither we nor GNU tar can read them.

> TAR header parsing attempts OLDGNU format on POSIX/STAR header
> --------------------------------------------------------------
>
>                 Key: COMPRESS-337
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-337
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.10
>            Reporter: Jeremy Gustie
>
> This is at least tangentially related to COMPRESS-336, we found an archive 
> which is misinterpreted as an OLDGNU header format when it appears to some 
> type of STAR header (unlike COMPRESS-336 this one uses a NULL delimiter 
> instead of space terminators for the time stamps). Apparently the archive 
> itself comes from an [EyeFi 
> card|https://github.com/golang/go/issues/5290](?!).
> Both the original archive ([available 
> here|https://storage.googleapis.com/go-attachment/5290/0/in.tar]) and the 
> (presumably hand made) version for testing 
> ([here|https://github.com/golang/go/raw/master/src/archive/tar/testdata/nil-uid.tar])
>  exhibit the same behavior: they fail with an {{IllegalArgumentException}} 
> attempting to parse the old GNU {{realSize}} from a buffer partially filled 
> with the {{atime}}/{{ctime}} values.
> At first I thought if the {{TarArchiveEntry.evaluateType}} were to also look 
> at the {{version}} field for {{VERSION_GNU_SPACE}} before returning 
> {{FORMAT_OLDGNU}} it _should_ be enough (according to something I saw in [the 
> GNU documentation|http://www.gnu.org/software/tar/manual/tar.html#SEC184] 
> which defines {{OLDGNU_MAGIC "ustar  "  /* 7 chars and a null */}}). 
> Unfortunately it looks like that is the magic/version used by the archives in 
> question, leaving me stumped as to how to identify which of the three 
> prevailing header formats needs to be parsed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to