Issue Details (XML | Word | Printable)

Key: TRUEZIP-286
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Christian Schlichtherle
Reporter: dantran
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
TrueZIP

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

Created: 20/Aug/12 04:03 PM   Updated: 19/Jul/13 07:24 PM   Resolved: 15/May/13 12:42 PM
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

Time Tracking:
Not Specified

Environment:

windows/unix

Issue Links:
Duplicate
 

Tags:
Participants: bodewig, Christian Schlichtherle and dantran



Christian Schlichtherle added a comment - 20/Aug/12 04:13 PM - 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.


Christian Schlichtherle added a comment - 20/Aug/12 04:37 PM - 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.


Christian Schlichtherle added a comment - 20/Aug/12 04:39 PM - edited

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


Christian Schlichtherle added a comment - 20/Aug/12 04:55 PM - 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.


Christian Schlichtherle added a comment - 20/Aug/12 05:07 PM

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


Christian Schlichtherle added a comment - 20/Aug/12 05:18 PM - 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 .


Christian Schlichtherle added a comment - 20/Aug/12 05:41 PM

Nope, using LONGFILE_POSIX doesn't change a thing.


Christian Schlichtherle added a comment - 23/Aug/12 05:45 PM

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


bodewig added a comment - 27/Dec/12 07:08 PM

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.


bodewig added a comment - 27/Dec/12 08:43 PM

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.


bodewig added a comment - 27/Dec/12 09:08 PM

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.


Christian Schlichtherle added a comment - 27/Dec/12 09:12 PM

Thanks a lot!