This bug report was migrated from our old Bugzilla tracker.
Reported in version: unspecified
Reported for operating system, platform: Linux, PC
Comments on the original bug report:
On 2009-01-11 07:13:57 -0500, wrote:
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.
On 2009-01-11 09:29:45 -0500, Ryan C. Gordon wrote:
Is the only invalid character 0x20? Perhaps older builds of tar filled this with space chars instead of nulls?
--ryan.
On 2009-01-11 10:14:00 -0500, Ryan C. Gordon wrote:
I think hg changeset 612:3c1b6b2f56c0 should resolve this.
--ryan.
On 2009-01-11 10:19:15 -0500, wrote:
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.
This bug report was migrated from our old Bugzilla tracker.
Reported in version: unspecified Reported for operating system, platform: Linux, PC
Comments on the original bug report:
On 2009-01-11 07:13:57 -0500, wrote:
On 2009-01-11 09:29:45 -0500, Ryan C. Gordon wrote:
On 2009-01-11 10:14:00 -0500, Ryan C. Gordon wrote:
On 2009-01-11 10:19:15 -0500, wrote: