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