[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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.


Attachment: signature.asc
Description: Digital signature

Reply to: