TrueZIP
  1. TrueZIP
  2. TRUEZIP-286

Unable to untar a TAR archive entry with a name length of more than 66 characters.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: TrueZIP 7.6, TrueZIP 7.6.1, TrueZIP 7.6.2, TrueZIP 7.6.3, TrueZIP 7.6.4, TrueZIP 7.6.5, TrueZIP 7.6.6, TrueZIP 7.7
    • Fix Version/s: TrueZIP 7.7.2
    • Component/s: TrueZIP Driver TAR
    • Labels:
      None
    • Environment:

      windows/unix

      Issue Links

        Activity

        Hide
        Christian Schlichtherle added a comment - - edited

        I have written a small round trip test and it appears the limit is 66 characters.

        The strange thing is that I call TarArchiveOutputStream.setLongFileMode(TarArchiveOutputStream.LONGFILE_GNU), so it may be a bug in commons-compress 1.4.1 - let me validate.

        Show
        Christian Schlichtherle added a comment - - edited I have written a small round trip test and it appears the limit is 66 characters. The strange thing is that I call TarArchiveOutputStream.setLongFileMode(TarArchiveOutputStream.LONGFILE_GNU), so it may be a bug in commons-compress 1.4.1 - let me validate.
        Hide
        Christian Schlichtherle added a comment - - edited

        First issue in TarArchiveOutputStream.putArchiveEntry, line 269: The array may be longer than the limit of the returned buffer, which is ignored. This is why the bug already appears with entry names of more than 66 (US-ASCII) characters.

        Show
        Christian Schlichtherle added a comment - - edited First issue in TarArchiveOutputStream.putArchiveEntry, line 269: The array may be longer than the limit of the returned buffer, which is ignored. This is why the bug already appears with entry names of more than 66 (US-ASCII) characters.
        Hide
        Christian Schlichtherle added a comment - - edited

        Second issue in line 284 of the same file: The oversized array (101 bytes instead of 67) is written to the TarArchiveOutputStream.

        Show
        Christian Schlichtherle added a comment - - edited Second issue in line 284 of the same file: The oversized array (101 bytes instead of 67) is written to the TarArchiveOutputStream.
        Hide
        Christian Schlichtherle added a comment - - edited

        Next issue: TarArchiveInputStream.getNextTarEntry() reads back in the oversized array and fails to truncate all null characters at the end - it discards only one null character in line 264.

        The resulting entry name is then padded with redundant null characters at its end, which is why ultimately my round trip test fails to locate the entry with its original name.

        Show
        Christian Schlichtherle added a comment - - edited Next issue: TarArchiveInputStream.getNextTarEntry() reads back in the oversized array and fails to truncate all null characters at the end - it discards only one null character in line 264. The resulting entry name is then padded with redundant null characters at its end, which is why ultimately my round trip test fails to locate the entry with its original name.
        Hide
        Christian Schlichtherle added a comment -

        Reported as an issue in Commons Compress 1.4.1: https://issues.apache.org/jira/browse/COMPRESS-200 .

        Show
        Christian Schlichtherle added a comment - Reported as an issue in Commons Compress 1.4.1: https://issues.apache.org/jira/browse/COMPRESS-200 .
        Hide
        Christian Schlichtherle added a comment - - edited

        Note to self: Consider using LONGFILE_POSIX instead of LONGFILE_GNU as a workaround: http://commons.apache.org/compress/apidocs/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.html#LONGFILE_POSIX .

        Show
        Christian Schlichtherle added a comment - - edited Note to self: Consider using LONGFILE_POSIX instead of LONGFILE_GNU as a workaround: http://commons.apache.org/compress/apidocs/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.html#LONGFILE_POSIX .
        Hide
        Christian Schlichtherle added a comment -

        Nope, using LONGFILE_POSIX doesn't change a thing.

        Show
        Christian Schlichtherle added a comment - Nope, using LONGFILE_POSIX doesn't change a thing.
        Hide
        Christian Schlichtherle added a comment -

        Dan, it might help if you vote for the JIRA issue #200 at commons-compress.

        Show
        Christian Schlichtherle added a comment - Dan, it might help if you vote for the JIRA issue #200 at commons-compress.
        Hide
        bodewig added a comment -

        I can see how Compress is using array() the wrong way, but I fail to create a simple testcase - the one I've committed to Compress' trunk passes). The posix testcase I've written passes as well and on first glance it shouldn't be affected by the array() mishap since nameBytes isn't used in that case.

        Show
        bodewig added a comment - I can see how Compress is using array() the wrong way, but I fail to create a simple testcase - the one I've committed to Compress' trunk passes). The posix testcase I've written passes as well and on first glance it shouldn't be affected by the array() mishap since nameBytes isn't used in that case.
        Hide
        bodewig added a comment -

        Rather than going back and forth between two JIRA instances, the key was to use an encoding other than the default encoding. Should be fixed in Compress' trunk soonish. I'll comment here once a fix is available in svn.

        Show
        bodewig added a comment - Rather than going back and forth between two JIRA instances, the key was to use an encoding other than the default encoding. Should be fixed in Compress' trunk soonish. I'll comment here once a fix is available in svn.
        Hide
        bodewig added a comment -

        Commons Compress svn trunk should be fixed now. There are a few other bug reports open that need to get addressed before we can cut a new release but it would be great if you could give the next SNAPSHOT build a try (or build trunk yourself). I guess COMPRESS-203 (not verified, yet) might hit TrueZIP users as well.

        Show
        bodewig added a comment - Commons Compress svn trunk should be fixed now. There are a few other bug reports open that need to get addressed before we can cut a new release but it would be great if you could give the next SNAPSHOT build a try (or build trunk yourself). I guess COMPRESS-203 (not verified, yet) might hit TrueZIP users as well.
        Hide
        Christian Schlichtherle added a comment -

        Thanks a lot!

        Show
        Christian Schlichtherle added a comment - Thanks a lot!

          People

          • Assignee:
            Christian Schlichtherle
            Reporter:
            dantran
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: