bzip plugin error

[onsager]

Currently, I encountered a problem with bzip, relating to long filenames (check http://ftp.gnome.org/pub/GNOME/sources/libsigc++/2.2/libsigc++-2.2.8.tar.bz2 for an example). The plugin seems to use some limit here, so different files in an archive are considered the same.

I found this error also in 7zip standalone version. My guess is, both pieces of software utilize the same sort of bzip code base.

On the other hand http://gnuwin32.sourceforge.net/packages/bzip2.htm doesn't have the problem and might provide some information, in order to fix the error.

[ghisler(Author)]

Thanks for the info. The problem isn't with bz2, but the internal TAR unpacker. The TAR file uses a format which is completely unknown to me. The name is too long for the tar header field, so it seems to use an extra header containing (when looking at the tar file with F3):

path=libsigc++-2.2.8/docs/reference/html/classsigc_1_1bound__argument_3_01const__reference__wrapper_3_01T__wrapped_01_4_01_4-members.html

Do you have any idea what program has created this TAR file? I need specifications to be able to handle this new file format.

[onsager]

Do you have any idea what program has created this TAR file? I need specifications to be able to handle this new file format.

No idea - but the mentioned working bzip2 from gnuwin32 uses some program called bsdtar (you can find recent versions here:http://code.google.com/p/libarchive/). Maybe, the sources for the [un]tar program provide some insight.

[ghisler(Author)]

I have checked the file in detail now - it's not a plain tar file, but a so-called "pax" file. This is using additional headers in POSIX.1-2001 format. I will add support for unpacking them.

[onsager]

I will add support for unpacking them.

Not to get on your nerve's - but that also means for the moment a limitation in writing any tar-based archives, if file names exceed a certain size. Probably right in a strict sense, if the tar specification imposes these limits. Personally, I wasn't aware of such a limitation up to now.

On the other hand, the pax format seems to be virtually indistinguishable on unixoids (to a certain extent), up to the point of the same file extension, in order to overcome tar's limitations. So, full read- and write-support is perhaps a good idea in the long run, even if the original tar format doesn't support these cases.

[ghisler(Author)]

TC uses already two different other methods (labeled as SunOS and Linux) to store extra-long names. I will consider to support PAX as a third option in TC 8.0.

[onsager]

TC uses already two different other methods (labeled as SunOS and Linux) to store extra-long names.

Ah, didn't knew that. In this case things are not that urgent, of course.

Thank you for the program by the way. I think, I'm using it for more than 10 years (?) now. You have a lot of loyal users, I can tell you that. :-)