On 05/04/2011 12:11 PM, Denys Vlasenko wrote:
> All this trouble just for the single one case where we store time?
It is probably a little over-generic. I found the issue when we
create a tar image for support reasons; since the reason we're doing
that is that the host is messed up, crazy timestamps are not uncommon
:)
> It's much easier to just add statbuf->st_mtime>= 0 ? statbuf->st_mtime : 0
> there.
This is fine if you wish; it should probably have a warning output
saying the file time was reset, to alert you something is going on.
But at least any POSIX tar will be able to read it.
> /* GNU tar uses "base-256 encoding" for very large
> numbers.
> * Encoding is binary, with highest bit always set
> as a marker
> * and sign in next-highest bit:
> * 80 00 .. 00 - zero
> * bf ff .. ff - largest positive number
> * ff ff .. ff - minus 1
> * c0 00 .. 00 - smallest negative number
> */
I'm not sure that description is actually correct. I believe the
first *byte* is always either 0x80 (+) or 0xff (-); at least I think
that was my reading of the tar source code. I reasoned that was
correct as it replaced the trailing NULL in octal formats.
> char *p8 = header.size + sizeof(header.size);
> do {
> *--p8 = (uint8_t)filesize;
> filesize>>= 8;
> } while (p8 != header.size);
> *p8 |= 0x80;
> } else {
> bb_error_msg_and_die("can't store file '%s' "
> "of size %"OFF_FMT"u, aborting",
> fileName, statbuf->st_size);
> }
Looks fine visually, I presume you tested it ;)
Cheers,
-i
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
