detail discussion is at http://java.net/projects/truezip/lists/users/archive/2012-08/message/5
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.
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.
Second issue in line 284 of the same file: The oversized array (101 bytes instead of 67) is written to the TarArchiveOutputStream.
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.
Reported as an issue in Commons Compress 1.4.1: https://issues.apache.org/jira/browse/COMPRESS-200 .
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 .
Nope, using LONGFILE_POSIX doesn't change a thing.
Dan, it might help if you vote for the JIRA issue #200 at commons-compress.
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.
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.
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.
Thanks a lot!