Stop extracting a RAR file if making huffman table fails, and report it in order to avoid an infinity loop
at reading damaged RAR files, which is made by test_fuzz.
When Skipping data in a store mode, use rar->bytes_remaining instead of rar->packed_size.
a use of packed_size in that case will not work after archive_read_format_rar_read_data
has been called.
Check the return value of __archive_read_consume in decoding lzss to avoid infinity loop in test_fuzz
because rar->bitoffset can have untrusted value when reading damaged RAR files.
Colin Percival [Tue, 2 Aug 2011 12:20:40 +0000 (08:20 -0400)]
Fix printing of INT(MAX|64)_MIN. In append_int we had theoretically
undefined behaviour, but the code probably worked on all existing
compilers and platforms. In format_int we could get the wrong output,
but only on files created/modified 280 billion years before the Big
Bang.
Colin Percival [Tue, 2 Aug 2011 08:56:27 +0000 (04:56 -0400)]
Make sure that the argument to --strip-components is a number. Otherwise
if someone accidentally omits the argument, we'll silently eat the next
command line argument. (GNU tar checks this, otherwise I wouldn't bother.)
Reduce a use of memory for decoding huffman code in both lha and cab reader.
Its side effect significantly reduces L1 cache miss observed with cachegrind,
which is one of valgrind tools.
Colin Percival [Mon, 1 Aug 2011 16:13:32 +0000 (12:13 -0400)]
Fix mtree_atol16. There was a missing ++(*p), with the result that the
values "0x[1-9].*" would be mapped to INT64_MAX, "0x-[1-9].*" would be
mapped to -INT64_MAX (which is another bug; it should have been INT64_MIN),
and "0x0.*" and "0x-0.*" would result in an infinite loop.
As part of this fix, factor out the duplicated digit-or-alpha-or-ALPHA
parsing into a separate function; I'm sure this complexity was responsible
for the increment getting lost in the first place.
Colin Percival [Mon, 1 Aug 2011 07:41:48 +0000 (03:41 -0400)]
Fix overflow handling in mtree_atol10. Prior to this commit, the value
"-9223372036854775808" (aka. -2^63 aka. INT64_MIN) will be parsed and
returned as -9223372036854775807 (aka. -INT64_MAX).
Tim Kientzle [Tue, 19 Jul 2011 05:02:05 +0000 (01:02 -0400)]
When scanning the beginning of an ASCII text file to see if it
has a uuencode 'begin' sequence, only examine the first 128k.
Extend the test to verify that we don't recognize uuencoded
data with 512k of leading ASCII data.
In iso9660 writer and xar writer, always overwrite the existing file in the file tree
which file has the same name; it is better that front-end applications such as tar decide
how they handle that case.
Add support for a pax textended keyword, "SUN.holesdata", which describes where is
data or hole in the stored contents. The pax of Solaris records the keyword when
using -x pax option which specify a pax format, and the file is sparse.
Tim Kientzle [Tue, 12 Jul 2011 05:35:22 +0000 (01:35 -0400)]
Remove dead files.
These also apparently ruffled some feathers:
http://code.google.com/p/libarchive/issues/detail?id=162
http://bugs.debian.org/614390
http://public.kitware.com/Bug/view.php?id=11885
The same changes of In the Xar writer, ignore ineffective path names in the Xar archive
such as "." , "/" or "../" and fix that handling. This is the same as the recent changes of
the ISO9660 writer.
In the ISO writer, ignore ineffective path names in the ISO9660 file system
such as "." , "/" or "../" and fix that handling. This is to improve r3464 changes.
In the fuzz test, improve the calculation of damaging bytes so as to
make at least one byte damage of the sample file even if its size is less than 100 bytes.
Fix issue 106. The original problem happned on linux platform and I fixed it onece
in r3277 but it was not sufficient. This change consider it could happen on other
platforms that the entry object has one sparse block and it indicates the whole file
data, which sparse block is made by other program code(not only our code).
Tim Kientzle [Sun, 26 Jun 2011 04:09:09 +0000 (00:09 -0400)]
Extend the --newer-than test to verify the behavior when there's a new
file inside an old directory. Rework the descent logic in write.c
somewhat to fix the behavior here.
Fix counting files read, dot not count it up when returning ARCHIVE_EOF.
Add the check of the return value of archive_file_count() into several
format reader tests.
This is the final step to reduce use of both read() and write() system-calls in the iso9660 writer.
- Stop reading the contents of each file from the temporary file with read().
- Read the block of all file contents instead, and then write it to next stream.
This is second step to reduce use of both read() and write() system-calls in the iso9660 writer.
- Copy file contents to wbuff, 64K buffer, and then write wbuff data with write() syscall when
the buffer is full.
- Improve wbuff handling to be able to be used for zisofs accordingly.
- Stop using wbuff as read buffer in setup_boot_information() function.
This is first step to reduce use of both read() and write() system-calls in the iso9660 writer.
- Use only one temporary file to be simple structure.
- When enabling zisofs, almost all files except a small(<2048 bytes) file are, consequently,
always compressed even if it is a boot file. The boot file will be uncompressed later.
- Write those files to the temporary file by 2048 bytes, though currently this is no effect.
Shift away "tar:utf8type=libarchive2x" option which is to read a pax file made with
libarchive 2.x in a wrong assumption of a wchar_t form in non UTF-8 locale;
use "tar:compat-2x" option instead.
And also add ""cpio:compat-2x" and "zip:compat-2x" to read filenames,
which are converted with CP_ACP, in those format on Windows plaform,
although you can use "hdrcharset=CP_ACP" option.
For posix like system:
- use "tar:compat-2x" option when you get incorrect filenames from pax
files made with bsdtar/libarchive 2.x.
For Windows system:
- use "tar:compat-2x", "cpio:compat-2x" and "zip:compat-2x" options
when you get incorrect filnames from those archives(except pax format)
made with bsdtar/libarchive 2.x.
Try to use "SJIS" character-set if use of "CP932" failed and a best effort bit is on,
because all of implements of iconv do not support "CP932" character-set and
"SJIS" character-set is widely supported more than "CP932".
Set SCONV_WIN_CP flag so that we use Windows API for UTF-16BE conversion
because IsValidCodePage(CP_UTF16BE) fails but we can handle it with byte-swapping.
projects / thirdparty / libarchive.git / log
