old tar file incompatibility

[SDLBugzilla]

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.

[icculus]

Looks like this might not have been completely fixed? Reopening to re-read more carefully later.