Uploaded image for project: 'Commons Compress'
  1. Commons Compress
  2. COMPRESS-344

Handle NULL terminated GNU AR extended name

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.10
    • Fix Version/s: 1.11
    • Component/s: Archivers
    • Labels:
      None

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              jgustie Jeremy Gustie
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: