[
https://issues.apache.org/jira/browse/COMPRESS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146501#comment-15146501
]
Stefan Bodewig commented on COMPRESS-336:
-----------------------------------------
The test archive is pretty nice as it shows a few shortcomings we have when
compared to GNU tar (and probably the Python lib that uses this for tests) ->
COMPRESS-338
> 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)
