tar: corrupted octal value in tar header (Apple Snow Leopard)

[Denys Vlasenko]

On Wed, Sep 23, 2009 at 5:55 AM, Peter Renzland <peter at dancing.org> wrote:
> On 09  Sep 20, at 19:31 , Denys Vlasenko wrote:
> On Sunday 20 September 2009 23:51, Peter Renzland wrote:
>>>
>>> It appears ironic that Snow Leopard, "The World's most advanced OS",
>>> has switched to the POSIX tar format, which according to BusyBox
>>> terminology requires "OLDGNU_COMPATIBILITY".
>>
>> I do not think that POSIX says that there must be trailing space in those
>> fields.
>
> It appears that POSIX did say that there *may* be terminating spaces (or
> NULL characters).
> From the NetBSD manual page for tar(5):
>
>        POSIX requires numeric fields to be zero-padded in
>    the front, and allows them to be terminated with either space or NUL
>    characters.
>
>> It's more likely that whoever was implementing tar
>> for Snow Leopard just "reused" code from some oldish tar
>> which was creating such fields, without much thinking why
>> this old code does that, and whether it makes sense
>> to continue to do that.
>
> Since there is no longer a current POSIX tar standard, perhaps it might make
> sense to create a Busybox term:
>
> "NEW APPLE COMPATIBILITY" which is equivalent to "OLDGNU COMPATIBILITY".

I think the question is: do we need to have FEATURE_TAR_OLDGNU_COMPATIBILITY
at all? Maybe it makes sense to make it unconditionally on.

It is less than 100 bytes:

function                                             old     new   delta
getOctal                                              63      57      -6
get_header_tar                                      1612    1533     -79
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-85)             Total: -85 bytes

What do you think?
--
vda