[
https://issues.apache.org/jira/browse/COMPRESS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873610#action_12873610
]
Christian Grobmeier commented on COMPRESS-113:
----------------------------------------------
Christian Grobmeier:
> > COMPRESS-113
> > TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when
> > parsing the octal
> > Suggestion from Sebb available. If a trailing NUL is in the tar specs,
> > I wold go for option 2 otherwise 1.
>
Stefan Bodewig
> If only there was *the* tar spec. The best source I know is the FreeBSD
> man page
>
> <http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current>
> and it says "must end in a space" for 'old archives' and "allows
> [numeric fields] to be terminated with either space or NUL". Similar
> rules (slightly twisted for 'old archives') apply to other fields than
> size as well, like mode or uid.
>
> I'd go with "insist on a trailing space or NUL".
It seems that there is a strong preference for option 2.
> TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when parsing
> the octal size
> --------------------------------------------------------------------------------------------
>
> Key: COMPRESS-113
> URL: https://issues.apache.org/jira/browse/COMPRESS-113
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Sebb
> Fix For: 1.1
>
>
> TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when parsing
> the octal size.
> Although the size field in the header is 12 bytes, the last byte is supposed
> to be space or NUL - i.e. only 11 octal digits are allowed for the size.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
