On Sun, Jul 26, 2015 at 02:10:10PM +0200, Antonio Diaz Diaz wrote: > >TBH this smells like FUD. For example I've never heard of corruption in > >.xz files due to non-robustness, I'd expect that corruption to come from > >external forces, and that integrity would help or not detect it. > > Sure it comes from external forces, but xz does something that no other > compressor does: even if the corruption does not affect the data and xz is > able to produce perfectly correct output, it will report "Compressed data is > corrupt" and will exit with non-zero status anyway. Just take any xz file > and append a null character to it. Bzip2, gzip and lzip simply ignore the > extra byte. > > But not only that. Xz is the only format (of the four mentioned) whose parts > need to be aligned to a multiple of four bytes. The size of a xz file must > also be a multiple of four bytes. To achieve this, xz includes padding > everywhere; after headers, blocks, the index, and the whole stream. The bad > news is that if the (useless) padding is altered in any way, "the decoder > MUST indicate an error" according to the xz format specification. > > This is specially bad when xz is used with tar, making the whole command to > fail and the whole archive to be discarded as corrupt. > > And this fragility is one of the perverse effects of the unbelievably stupid > design of xz; "It is possible that there is a new field present which the > decoder is not aware of, and can thus parse the Block Header > incorrectly[1]". > > [1] http://tukaani.org/xz/xz-file-format.txt (see 3.1.6. Header Padding) > > So yes, the xz format is objectively more fragile than the other three. Looks like you've completely missed the point and decided to refute a straw man. > >Whenever considering to add a new compressor, all surrounding tools need > >to be modified to support it as well: > > The future is long. You can save a lot of work in the long term by adding > lzip and deprecating the rest. (or vice versa) > You can repeat that .xz is superior to .lz as much as you want, but this > won't make it true. The xz format is so bad that it manages to be as bad for > long-term archiving as lzma-alone. Meanwhile lziprecover achieves the > unprecedented feat of repairing single-byte errors without the help of any > extra redundance. Why is this relevant on this thread? > I am not here to "win", but to help people keep their data safe. Looks like you don't understand what use case is discussed here. -- WBR, wRAR
Attachment:
signature.asc
Description: Digital signature