On Wed, Jul 8, 2009 at 11:11 AM, T4ndeta<[email protected]> wrote:
> Hi,
>
> Today I came a cross a strange tar archive which couldn't been
> extracted by tar from busybox (tested on recent snapshot).
> I checked that this archive has files/directories with creation date about
> 1920.
> Looks like very old dates are stored in different manner then dates above
> 1970.
>
> Here is what I changed to solve my problem
> file: /archival/libunarchive/get_header_tar.c
> @@ -301,7 +303,9 @@
> file_header->uname = tar.uname[0] ? xstrndup(tar.uname,
> sizeof(tar.uname)) : NULL;
> file_header->gname = tar.gname[0] ? xstrndup(tar.gname,
> sizeof(tar.gname)) : NULL;
> #endif
> - file_header->mtime = GET_OCTAL(tar.mtime);
> + file_header->mtime = *tar.mtime == 0xFF /* positive base256? */
No, 0xFF (and any byte of the form 11xxxxxx) is _negative_ base256.
And therefore:
> + ? getBase256_len12(tar.mtime)
this is wrong: see a comment at getBase256_len12 - it does not handle
negative numbers, and also it expects a specific alignment.
> + : GET_OCTAL(tar.mtime);
> /* Size field: handle GNU tar's "base256 encoding" */
> file_header->size = (*tar.size & 0xc0) == 0x80 /* positive base256? */
> ? getBase256_len12(tar.size)
>
> Don't know if the condition is good for all situation, but it did work
> in my case
On x86, which does not have alignment faults, yes.
How about this?
/* mtime: rudimentally handle GNU tar's "base256 encoding"
* People report tarballs with NEGATIVE unix times encoded that way */
file_header->mtime = (tar.mtime[0] & 0x80) /* base256? */
? 0 /* bogus */
: GET_OCTAL(tar.mtime);
/* size: handle GNU tar's "base256 encoding" */
file_header->size = (tar.size[0] & 0xc0) == 0x80 /* positive base256? */
? getBase256_len12(tar.size)
: GET_OCTAL(tar.size);
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
