The second argument to text_hole_delete was incorrect: it should
be a pointer to the end of the hole.
Signed-off-by: Ron Yorston <rmy@tigress.co.uk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Added -a support. Also made sure -f works as follows:
losetup [-r] [-o offset] {-f|loopdev} file
Removed support for 'losetup -r' with no arguments.
Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This makes reading the logic (as well as adding new code) a lot simpler,
and fixes one or two cases that were broken due to incorrect sub-version
tests.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The realpath utility requires all paths exist when canonicalizing
symlinks. If /etc/resolv.conf points to a tmpfs, then it might
not exist initially. Use `readlink -f` so that we follow all
symlinks that are available.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
It is not slower. In fact it seems a tiny bit faster too.
text data bss dec hex filename
2827 0 0 2827 b0b decompress_unlzma.o
2797 0 0 2797 aed decompress_unlzma.o
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The -q flag is used in shell scripts for suppressing output.
Have our applets swallow the flag for compatibility.
Reported-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Because when -x is used (exact match), then we cannot compile the
regular expression with REG_NOSUB. The manual page regcomp(3) states
in section "Byte offsets":
Unless REG_NOSUB was set for the compilation of the pattern
buffer, it is possible to obtain substring match addressing
information.
The problem was detected on an ARM system with glibc 2.16.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The "big" run-parts supports a handy --exit-on-error to stop execution on
errors, so lets support it as well.
Upstream doesn't have a short option for it, but I've used '-e' for busybox.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In vi mode, the 'p' and 'P' commands caused a segfault when nothing had
been put in the buffer yet because the delptr was not initialized.
Signed-off-by: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
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>
