I have the Loki port of CIV CTP, on the cd there is a file named CivCTP-data.tar.gz on the German version and CivCTP.tar.gz on the English version of that game.
I could not get mojosetup to install the files from that archive, it always showed the error message: "Unknown file archive" before it stopped.
So I had a look at the source code and the problem is mainly in the function octal_convert in archive_tar.c.
For example the file size field looks like:
20 20 20 20 20 20 20 31 37 31 31 20 (12 bytes)
* contains bytes which are no valid octal values (0x20)
(seems like unused fields are not zero filled)
So 0 is always returned by this function.
file mode fields looks like this:
31 30 30 36-34 34 20
and so a wrong value is returned here too.
I'm not sure why this tar archive is different but GNU tar has no problem with those tar files.
As a hack I added
//seek first octal value
while((*str < '0') || (*str > '7'))
str++;
which 'fixes' the wrong file length problem.
I would propose to rewrite the tar File header parsing to make it less error-prone.
Yes only 0x20 so far.
Here is some information I found on the internet:
Early tar implementations varied in how they terminated these fields. The tar command in AT&T System v7 used the following conventions (this is also documented in early BSD manpages): the pathname must be null-terminated; the mode, uid, and gid fields must end in a space and a null byte; the size and mtime fields must end in a space; the checksum is terminated by a null and a space. Early implementations filled the numeric fields with leading spaces. This seems to have been common practice until the St -p1003.1-88 standard was released. For best portability, modern implementations should fill the numeric fields with leading zeros.
I have the Loki port of CIV CTP, on the cd there is a file named CivCTP-data.tar.gz on the German version and CivCTP.tar.gz on the English version of that game. I could not get mojosetup to install the files from that archive, it always showed the error message: "Unknown file archive" before it stopped. So I had a look at the source code and the problem is mainly in the function octal_convert in archive_tar.c. For example the file size field looks like: 20 20 20 20 20 20 20 31 37 31 31 20 (12 bytes) * contains bytes which are no valid octal values (0x20) (seems like unused fields are not zero filled) So 0 is always returned by this function. file mode fields looks like this: 31 30 30 36-34 34 20 and so a wrong value is returned here too. I'm not sure why this tar archive is different but GNU tar has no problem with those tar files. As a hack I added //seek first octal value while((*str < '0') || (*str > '7')) str++; which 'fixes' the wrong file length problem. I would propose to rewrite the tar File header parsing to make it less error-prone.