Major Description
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.