Failed to decode a block: CRC32 check failed
walt-ko opened this issue · comments
walt@stag:~/Public$ ls -l linux-6.1.13_32.tar.bz3
-rw-r--r-- 1 walt walt 131233163 Feb 24 04:36 linux-6.1.13_32.tar.bz3
walt@stag:~/Public$ sha256sum -b linux-6.1.13_32.tar.bz3
af202fcf0964910536fe862a6dca47c858f867cad4e054873ce4f12c0ceeb384 *linux-6.1.13_32.tar.bz3
walt@stag:~/Public$ /usr/bin/bzip3 --version
bzip3 1.2.2
Copyright (C) by Kamila Szewczyk, 2022.
License: GNU Lesser GPL version 3 <https://www.gnu.org/licenses/lgpl-3.0.en.html>
walt@stag:~/Public$ time /usr/bin/bzip3 -tv linux-6.1.13_32.tar.bz3
linux-6.1.13_32.tar.bz3:OK, 131233163 bytes read.
real 1m8.449s
user 1m8.409s
sys 0m0.040s
walt@stag:~/Public$ /usr/local/bin/bzip3 --version
bzip3 1.3.1
Copyright (C) by Kamila Szewczyk, 2022-2023.
License: GNU Lesser GPL version 3 <https://www.gnu.org/licenses/lgpl-3.0.en.html>
walt@stag:~/Public$ time /usr/local/bin/bzip3 -tv linux-6.1.13_32.tar.bz3
Failed to decode a block: CRC32 check failed
real 0m1.843s
user 0m1.823s
sys 0m0.020s
walt@stag:~/Public$
Hello.
Thanks for reporting the issue. The CRC computation code has changed in 1.2.3 because of the endianness issues reported by a FreeBSD maintainer. Recompressing the archive is an option. Alternatively, I am going to push an update in a couple of minutes that adds the -r ("recover") flag which will decode the blocks regardless of their checksum. Obviously, no data is lost in this case, but it may be helpful to combat storage media-induced corruption.
From master:
$ ./bzip3-1.2.1 -feb 2 segment1.fla
$ ./bzip3-1.3.2 -df segment1.fla.bz3
Failed to decode a block: CRC32 check failed
$ ./bzip3-1.3.2 -rf segment1.fla.bz3 2>/dev/null
Decodes the file properly.
walt@stag:/usr/local/src/compression/bzip3/bzip3-20230309/.libs$ LD_LIBRARY_PATH=. ldd ./bzip3
linux-vdso.so.1 (0x00007ffc48fbb000)
libbzip3.so.1 => ./libbzip3.so.1 (0x00007fa57af3c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa57ad32000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa57af5a000)
walt@stag:/usr/local/src/compression/bzip3/bzip3-20230309/.libs$ LD_LIBRARY_PATH=. ./bzip3 --version
bzip3 1.2.3
Copyright (C) by Kamila Szewczyk, 2022.
License: GNU Lesser GPL version 3 <https://www.gnu.org/licenses/lgpl-3.0.en.html>
walt@stag:/usr/local/src/compression/bzip3/bzip3-20230309/.libs$ LD_LIBRARY_PATH=. ./bzip3 -tv ~/Public/linux-6.1.13_32.tar.bz3
/home/walt/Public/linux-6.1.13_32.tar.bz3:OK, 131233163 bytes read.
walt@stag:/usr/local/src/compression/bzip3/bzip3-20230309/.libs$
Hello.
I think, if you change checksum algorithm, you should change file format version.
So my proposal, change format version, to calculate with a new only algo.
For previous version calculate both sums for 1st block, than choose correct algo.
walt
Also I think, this incompatibility prevents Debian Team to update bzip3 in repository.
Hello.
This incompatibility is not the thing that prevents Debian from updating bzip3 - the maintainers were slow to update bzip3 in the past regardless of the changes.
I have to agree with walt-ko. If you compress a file, then your software distributor upgrades bzip3, and as a result you cannot decompress your file, it's a bug. Especially if NEWS file does not mention it.
To prevent from future surprises, I recommend adding a small bzip3 archive into the tests and decompressing it when performing the tests. Actually Makefile.am would deserve a proper "make check" target https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html.
Fixed in v1.3.2, you can decompress 1.3.x (x<=1) archives using bzip3 -rd. Sorry about that.