function old new delta
xz_dec_reset - 77 +77
unpack_xz_stream 2402 2397 -5
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
xz_dec_run() could incorrectly return XZ_BUF_ERROR if
all of the following was true:
- The caller knows how many bytes of output to expect
and only provides that much output space.
- When the last output bytes are decoded, the
caller-provided input buffer ends right before
the LZMA2 end of payload marker. So LZMA2 won't
provide more output anymore, but it won't know it
yet and thus won't return XZ_STREAM_END yet.
- A BCJ filter is in use and it hasn't left any
unfiltered bytes in the temp buffer. This can happen
with any BCJ filter, but in practice it's more likely
with filters other than the x86 BCJ.
This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=735408>
where Squashfs thinks that a valid file system is corrupt.
Thanks to Jindrich Novy for telling me that such a bug report
exists, Phillip Lougher for providing excellent debug info,
and other people on #fedora-ppc.
This also fixes a similar bug in single-call mode where the
uncompressed size of a XZ Block using BCJ + LZMA2 was 0 bytes
and caller provided no output space. Many empty .xz files
don't contain any Blocks and thus don't trigger this bug.
This also tweaks a closely related detail: xz_dec_bcj_run()
could call xz_dec_lzma2_run() to decode into temp buffer when
it was known to be useless. This was harmless although it
wasted a minuscule number of CPU cycles.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
No .xz encoder creates files with empty LZMA2 streams,
but such files would still be valid and decompressors
must accept them.
Note that empty .xz files are a different thing than
empty LZMA2 streams. This bug didn't affect typical .xz
files that had no uncompressed data.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Users were reporting getting errors like
"ls: error while loading shared libraries: libc.so.6: ELF load command past end of file"
while rpm was unpacking glibc tarball.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
99% plus of all people who'll get corrupted archive wouldn't bother
debugging it. The rest can uncomment the code.
function old new delta
unpack_Z_stream 1304 1234 -70
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
While at it, fix filename order and free the list of names.
function old new delta
llist_rev - 21 +21
get_header_tar 1733 1741 +8
unpack_package 587 585 -2
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/1 up/down: 29/-2) Total: 27 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This makes unzip to FAT filesystems not exit with error.
This is similar to how the "normal" unzip works.
Signed-off-by: Natanael Copa <natanael.copa@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Now get_header_tar_gz, get_header_tar_bz2, get_header_tar_lzma
are only used if dpkg is built.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
unpack_gz_stream_with_info: fix buggy error check
man: fix possible accesses past the end of a string
move seamless uncompression helpers from read_printf.c to open_transformer.c
function old new delta
show_manpage 153 212 +59
unpack_gz_stream_with_info 520 539 +19
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Enabling the config option on my standard linux box and zipping a
random 250mb file:
small mem: 21.85user 0.44system 0:22.35elapsed
big mem: 13.45user 0.46system 0:13.94elapsed
Signed-off-by: Ian Wienand <ianw@vmware.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
