The version of 'tar' supplied with UnTarBZ2 doesn't cope with filenames > 99 chars

A lot of people have been reporting problems with extracting source archives using UnTarBZ2. After trying it myself today, I’ve been able to recreate the issues, and it looks like it all comes down to the fact that the version of tar supplied with UnTarBZ2 doesn’t contain any workarounds for the 100 character file name limit inherent in the tar format

It looks like there are two seperate issues with file name lengths which will cause problems:

1. When the archive was being created, any name over 100 characters long will have had leading directories stripped from the filename. E.g. “TungstenDev/mixed/RiscOS/Sources/ThirdParty/OSLib/Lib/OSLib/Dist/OSLib/User/oslib/h/remoteprintersupport” becomes “mixed/RiscOS/Sources/ThirdParty/OSLib/Lib/OSLib/Dist/OSLib/User/oslib/h/remoteprintersupport”, which causes the file to be extracted to the wrong place on extraction.
2. If a filename is exactly 100 characters long, it will have “000640” appended to it on extraction. This is because the ‘name’ buffer is adjacent to the ‘mode’ buffer (see the link above), and the file’s unix mode was 000640.

Interestingly, WinRAR copes fine with #1, but fails with #2 (although my copy of WinRAR is 6 years old anyway, so there’s a good chance that bug has been fixed by now).

It looks like there are multiple different tar format variants available, presumably all of them designed to cope with limitations like the 100 character name limit. E.g. the version of GNU tar on the riscos.info site supports the following formats:

• gnu (GNU tar 1.13 and above)
• oldgnu (GNU tar 1.12 and below)
• pax (POSIX 1003.1-2001)
• posix (same as pax, apparently)
• ustar (POSIX 1003.1-1988)
• v7 (“old V7 tar format”)

Unfortunately we can’t simply switch to the version of tar that’s on riscos.info because it’s broken :( (It doesn’t seem to swap /’s for .’s properly, resulting in directories called “TungstenDev/bsd”, etc.) Plus it would probably need a patch for handling the ,xxx filetype extensions anyway.

So, two questions:

1. What format of tar file are we dealing with
2. What’s better – fixing the tar we’ve got now, or fixing the riscos.info tar? Or fixing both?

Unfortunately we can’t simply switch to the version of tar that’s on riscos.info because it’s broken :( (It doesn’t seem to swap /’s for .’s properly, resulting in directories called “TungstenDev/bsd”, etc.)

After playing with the latest riscos.info tar a bit more, it looks like this problem can be easily solved with the following:

*set UnixEnv$tar$sfix ""

This will allow the tar to be extracted correctly, apart from the ,xxx extensions not being handled. But that can easily be dealt with with a simple BASIC script, or maybe an improved version of EraseCVS. The riscos.info version of tar can also un-bzip the file on-the-fly, which will surely save a bit of time/disc space (especially for people using SCSIFS on their beagles).

The riscos.info version of tar can also un-bzip the file on-the-fly

Except it can’t, because I’ve just tried it :( It relies in the bzip2 utility being present, and just pipes the output between the two tools (which for unixlib seems to have been implemented by just writing a temporary file to the scrap folder).

I suspect replacing the tar utility in UnTarBZ2 with the current one from riscos.info and adding a stage to fix-up the ,xxx suffixes into filetypes might be the way forward. I’ll add it to my ToDo list.