3 ms·
Zstd is still just as bad when it comes to the most important point: >Xz does not provide any data recovery means For the common use case of compression a tar
by kiririn 4y ago
Zstd is still just as bad when it comes to the most important point:
>Xz does not provide any data recovery means
For the common use case of compression a tar archive, this is a critical flaw. One small area of corruption will render the remainder of the archive unreadable.
I don’t know how we found ourselves with the best formats for data recovery/robustness fading into obscurity - i.e lzip and to lesser extent bzip2.
The only compressed format left in common use that handles corruption is the hardware compression in LTO tape drives
- armitron 4y agoZstd is terrible for archiving since it doesn't even detect corruption. The --check switch described in the manpage as enabling checksums (in a super-confusing way) seems to do absolutely nothing. You can test by intentionally corrupting a .zstd file that was created with checksums enabled and then watch as zstd happily proceeds to decompress it, without any sort of warning. This is the stuff of nightmares. After all these years, RAR remains the best option for archiving.
- btdmaster 4y agoI got "Decoding error (36)" when data was wrong, so --check (enabled by default during compression) is working for me: echo 'a b c' > test zstd test zstdcat test.zst sed -i s/a/b/g test.zst # corrupt the file on purpose zstdcat test.zst
- tablespoon 4y ago> I don’t know how we found ourselves with the best formats for data recovery/robustness fading into obscurity - i.e lzip and to lesser extent bzip2. Because monotonically increasing technological progress is a commonly-believed fairy tale. Nowadays, capabilities are lost as often as they're gained. Either because the people who designed the successor are being opinionated or just focusing on something else.