bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] octal reading in spec


From: Paul Eggert
Subject: Re: [Bug-tar] octal reading in spec
Date: Fri, 11 Aug 2006 00:39:34 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

"Sergey Poznyakoff" <address@hidden> writes:
"Sergey Poznyakoff" <address@hidden> writes:

> According to the POSIX specs all numeric fields are leading zero-filled
> octal numbers.

Yes, but the fields must be "terminated by one or more <space> or NUL
characters."

>     Fill in the checksum field.  It's formatted differently from the
>     other fields: it has [6] digits, a null, then a space -- rather
>     than digits, then a null.
>
> Whoever wrote it must have had some reasons to do so. However, in my
> understanding, it is a mis-feature.
>
> Paul, could you shed some light on it?

No doubt GNU tar was mimicking 7th Edition Unix 'tar' here.
7th Edition Unix 'tar' first set the entire checksum area to spaces;
then it calculated the checksum using the spaces (as POSIX requires);
then it used sprintf(checksum field, "%6o", checksum value); hence it
always had 6 octal digits, then a null byte, then the space left over
from the checksum calculation.

This behavior no longer survives in Solaris 8 through 10 tar; it
generates 7 octal digits followed by a null byte.

As far as I can tell, both behaviors fully conform to the standard,
since once you see a space or a NUL you're supposed to stop scanning.
That is what 7th edition Unix 'tar' does, i.e., it won't care which
format is used when it reads the checksum.

I suppose you could change GNU tar to match the Solaris behavior if
you like, as that's a bit cleaner.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]