commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Resolved] (COMPRESS-344) Handle NULL terminated GNU AR extended name
Date Tue, 22 Mar 2016 17:17:25 GMT


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:
>             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|]
project, the {{sigar-bin/lib/sigar-x86-winnt.lib}} archive from the [1.6.3 distribution|]
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

View raw message