You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2016/02/14 12:05:18 UTC

[jira] [Resolved] (COMPRESS-336) Extended Standard TAR format prefix is 130 characters

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

Stefan Bodewig resolved COMPRESS-336.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.11

should be fixed with commit 32633c3

Many thanks for the analysis.

> Extended Standard TAR format prefix is 130 characters
> -----------------------------------------------------
>
>                 Key: COMPRESS-336
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-336
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.10
>            Reporter: Jeremy Gustie
>             Fix For: 1.11
>
>
> A TAR archive created with star having an artype of "xstar" apparently limits the PREFIX to 130 characters to accommodate an access time and a creation time (this much I was able to learn from the star man page). I wasn't able to track down any specifics about the format, but in at least the first example I found, it appears that the access and creation time are stored as two space terminated ASCII numbers at the end of what would otherwise be the prefix.
> Currently, the code will read this type of archive and assume the prefix is 131 NULs followed by the two ASCII time stamps. Needless to say, it makes a mess of the entry names.
> I'm not 100% sure of the implementation, but perhaps something like (with {{XSTAR_PREFIXLEN}} == 130):
> {code}
> default: {
>   final int prefixlen = header[offset + XSTAR_PREFIXLEN + 1] == 0 ? XSTAR_PREFIXLEN : PREFIXLEN;
>   String prefix = oldStyle
>     ? TarUtils.parseName(header, offset, prefixlen)
>     : TarUtils.parseName(header, offset, prefixlen, encoding);
>   // ...
> }
> {code}
> Maybe a separate feature request would be appropriate for capturing and exposing the additional timestamps?



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