tar: corrupted octal value in tar header (Apple Snow Leopard)
Peter Renzland
peter at dancing.org
Wed Sep 23 14:07:52 UTC 2009
On 09 Sep 23, at 07:11 , Denys Vlasenko wrote:
> 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
This sounds like a good idea, resulting in greater simplicity and
portability.
More information about the busybox
mailing list