[
https://issues.apache.org/jira/browse/COMPRESS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-344.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.11
How do you always find these edge cases :-)
should be fixed with git commit a5eca56
Thanks a lot.
> Handle NULL terminated GNU AR extended name
> -------------------------------------------
>
> Key: COMPRESS-344
> URL: https://issues.apache.org/jira/browse/COMPRESS-344
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.10
> Reporter: Jeremy Gustie
> Fix For: 1.11
>
>
> We have an AR archive (a .lib file) whose extended name is terminated by a
> NULL instead of a line feed which causes an {{IOException}} ("Failed to read
> entry: 0"). It looks like {{ArArchiveInputStream.getExtendedName}} just needs
> to check {{namebuffer\[i\]}} for {{'\012'}} _or_ 0.
> The ar tool in latest GNU binutils seems to be able to handle this.
> I don't know what to make of the archive itself: it seems to contain 291
> different copies of a file with the same name; but it is a Windows lib file
> and I am not going to pretend like I understand if this is supposed to be
> normal or not.
> The file in question is part of the
> [SIGAR|https://support.hyperic.com/display/SIGAR/Home] project, the
> {{sigar-bin/lib/sigar-x86-winnt.lib}} archive from the [1.6.3
> distribution|https://sourceforge.net/projects/sigar/files/sigar/1.6/hyperic-sigar-1.6.3.tar.gz/download]
> exhibits this behavior. The NULL terminated string only appears in the first
> file, all subsequent files seem to use the expected line feed terminator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
