[TRUEZIP-286] Unable to untar a TAR archive entry with a name length of more than 66 characters. Created: 20/Aug/12  Updated: 19/Jul/13  Resolved: 15/May/13

Status: Closed
Project: TrueZIP
Component/s: TrueZIP Driver TAR
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

Type: Bug Priority: Major
Reporter: dantran Assignee: Christian Schlichtherle
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Issue Links:
is duplicated by TRUEVFS-15 CLONE -Unable to untar a TAR archive ... Closed


detail discussion is at http://java.net/projects/truezip/lists/users/archive/2012-08/message/5

Comment by Christian Schlichtherle [ 20/Aug/12 ]

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.

Comment by Christian Schlichtherle [ 20/Aug/12 ]

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.

Comment by Christian Schlichtherle [ 20/Aug/12 ]

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

Comment by Christian Schlichtherle [ 20/Aug/12 ]

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.

Comment by Christian Schlichtherle [ 20/Aug/12 ]

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

Comment by Christian Schlichtherle [ 20/Aug/12 ]

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 .

Comment by Christian Schlichtherle [ 20/Aug/12 ]

Nope, using LONGFILE_POSIX doesn't change a thing.

Comment by Christian Schlichtherle [ 23/Aug/12 ]

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

Comment by bodewig [ 27/Dec/12 ]

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.

Comment by bodewig [ 27/Dec/12 ]

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.

Comment by bodewig [ 27/Dec/12 ]

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.

Comment by Christian Schlichtherle [ 27/Dec/12 ]

Thanks a lot!

Generated at Thu Mar 30 17:50:22 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.