1 2XZ Utils Release Notes 3====================== 4 55.0.3 (2011-05-21) 6 7 * liblzma fixes: 8 9 - A memory leak was fixed. 10 11 - lzma_stream_buffer_encode() no longer creates an empty .xz 12 Block if encoding an empty buffer. Such an empty Block with 13 LZMA2 data would trigger a bug in 5.0.1 and older (see the 14 first bullet point in 5.0.2 notes). When releasing 5.0.2, 15 I thought that no encoder creates this kind of files but 16 I was wrong. 17 18 - Validate function arguments better in a few functions. Most 19 importantly, specifying an unsupported integrity check to 20 lzma_stream_buffer_encode() no longer creates a corrupt .xz 21 file. Probably no application tries to do that, so this 22 shouldn't be a big problem in practice. 23 24 - Document that lzma_block_buffer_encode(), 25 lzma_easy_buffer_encode(), lzma_stream_encoder(), and 26 lzma_stream_buffer_encode() may return LZMA_UNSUPPORTED_CHECK. 27 28 - The return values of the _memusage() functions are now 29 documented better. 30 31 * Fix command name detection in xzgrep. xzegrep and xzfgrep now 32 correctly use egrep and fgrep instead of grep. 33 34 * French translation was added. 35 36 375.0.2 (2011-04-01) 38 39 * LZMA2 decompressor now correctly accepts LZMA2 streams with no 40 uncompressed data. Previously it considered them corrupt. The 41 bug can affect applications that use raw LZMA2 streams. It is 42 very unlikely to affect .xz files because no compressor creates 43 .xz files with empty LZMA2 streams. (Empty .xz files are a 44 different thing than empty LZMA2 streams.) 45 46 * "xz --suffix=.foo filename.foo" now refuses to compress the 47 file due to it already having the suffix .foo. It was already 48 documented on the man page, but the code lacked the test. 49 50 * "xzgrep -l foo bar.xz" works now. 51 52 * Polish translation was added. 53 54 555.0.1 (2011-01-29) 56 57 * xz --force now (de)compresses files that have setuid, setgid, 58 or sticky bit set and files that have multiple hard links. 59 The man page had it documented this way already, but the code 60 had a bug. 61 62 * gzip and bzip2 support in xzdiff was fixed. 63 64 * Portability fixes 65 66 * Minor fix to Czech translation 67 68 695.0.0 (2010-10-23) 70 71 Only the most important changes compared to 4.999.9beta are listed 72 here. One change is especially important: 73 74 * The memory usage limit is now disabled by default. Some scripts 75 written before this change may have used --memory=max on xz command 76 line or in XZ_OPT. THESE USES OF --memory=max SHOULD BE REMOVED 77 NOW, because they interfere with user's ability to set the memory 78 usage limit himself. If user-specified limit causes problems to 79 your script, blame the user. 80 81 Other significant changes: 82 83 * Added support for XZ_DEFAULTS environment variable. This variable 84 allows users to set default options for xz, e.g. default memory 85 usage limit or default compression level. Scripts that use xz 86 must never set or unset XZ_DEFAULTS. Scripts should use XZ_OPT 87 instead if they need a way to pass options to xz via an 88 environment variable. 89 90 * The compression settings associated with the preset levels 91 -0 ... -9 have been changed. --extreme was changed a little too. 92 It is now less likely to make compression worse, but with some 93 files the new --extreme may compress slightly worse than the old 94 --extreme. 95 96 * If a preset level (-0 ... -9) is specified after a custom filter 97 chain options have been used (e.g. --lzma2), the custom filter 98 chain will be forgotten. Earlier the preset options were 99 completely ignored after custom filter chain options had been 100 seen. 101 102 * xz will create sparse files when decompressing if the uncompressed 103 data contains long sequences of binary zeros. This is done even 104 when writing to standard output that is connected to a regular 105 file and certain additional conditions are met to make it safe. 106 107 * Support for "xz --list" was added. Combine with --verbose or 108 --verbose --verbose (-vv) for detailed output. 109 110 * I had hoped that liblzma API would have been stable after 111 4.999.9beta, but there have been a couple of changes in the 112 advanced features, which don't affect most applications: 113 114 - Index handling code was revised. If you were using the old 115 API, you will get a compiler error (so it's easy to notice). 116 117 - A subtle but important change was made to the Block handling 118 API. lzma_block.version has to be initialized even for 119 lzma_block_header_decode(). Code that doesn't do it will work 120 for now, but might break in the future, which makes this API 121 change easy to miss. 122 123 * The major soname has been bumped to 5.0.0. liblzma API and ABI 124 are now stable, so the need to recompile programs linking against 125 liblzma shouldn't arise soon. 126 127