diff options
Diffstat (limited to 'storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt')
6 files changed, 1030 insertions, 0 deletions
diff --git a/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xz.txt b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xz.txt new file mode 100644 index 00000000..e9b0ee5e --- /dev/null +++ b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xz.txt @@ -0,0 +1,786 @@ +XZ(1) XZ Utils XZ(1) + + + +NAME + xz, unxz, xzcat, lzma, unlzma, lzcat - Compress or decompress .xz and + .lzma files + +SYNOPSIS + xz [option]... [file]... + + unxz is equivalent to xz --decompress. + xzcat is equivalent to xz --decompress --stdout. + lzma is equivalent to xz --format=lzma. + unlzma is equivalent to xz --format=lzma --decompress. + lzcat is equivalent to xz --format=lzma --decompress --stdout. + + When writing scripts that need to decompress files, it is recommended + to always use the name xz with appropriate arguments (xz -d or xz -dc) + instead of the names unxz and xzcat. + +DESCRIPTION + xz is a general-purpose data compression tool with command line syntax + similar to gzip(1) and bzip2(1). The native file format is the .xz + format, but also the legacy .lzma format and raw compressed streams + with no container format headers are supported. + + xz compresses or decompresses each file according to the selected oper- + ation mode. If no files are given or file is -, xz reads from standard + input and writes the processed data to standard output. xz will refuse + (display an error and skip the file) to write compressed data to stan- + dard output if it is a terminal. Similarly, xz will refuse to read com- + pressed data from standard input if it is a terminal. + + Unless --stdout is specified, files other than - are written to a new + file whose name is derived from the source file name: + + o When compressing, the suffix of the target file format (.xz or + .lzma) is appended to the source filename to get the target file- + name. + + o When decompressing, the .xz or .lzma suffix is removed from the + filename to get the target filename. xz also recognizes the suf- + fixes .txz and .tlz, and replaces them with the .tar suffix. + + If the target file already exists, an error is displayed and the file + is skipped. + + Unless writing to standard output, xz will display a warning and skip + the file if any of the following applies: + + o File is not a regular file. Symbolic links are not followed, thus + they are never considered to be regular files. + + o File has more than one hardlink. + + o File has setuid, setgid, or sticky bit set. + + o The operation mode is set to compress, and the file already has a + suffix of the target file format (.xz or .txz when compressing to + the .xz format, and .lzma or .tlz when compressing to the .lzma for- + mat). + + o The operation mode is set to decompress, and the file doesn't have a + suffix of any of the supported file formats (.xz, .txz, .lzma, or + .tlz). + + After successfully compressing or decompressing the file, xz copies the + owner, group, permissions, access time, and modification time from the + source file to the target file. If copying the group fails, the permis- + sions are modified so that the target file doesn't become accessible to + users who didn't have permission to access the source file. xz doesn't + support copying other metadata like access control lists or extended + attributes yet. + + Once the target file has been successfully closed, the source file is + removed unless --keep was specified. The source file is never removed + if the output is written to standard output. + + Sending SIGINFO or SIGUSR1 to the xz process makes it print progress + information to standard error. This has only limited use since when + standard error is a terminal, using --verbose will display an automati- + cally updating progress indicator. + + Memory usage + The memory usage of xz varies from a few hundred kilobytes to several + gigabytes depending on the compression settings. The settings used when + compressing a file affect also the memory usage of the decompressor. + Typically the decompressor needs only 5 % to 20 % of the amount of RAM + that the compressor needed when creating the file. Still, the worst- + case memory usage of the decompressor is several gigabytes. + + To prevent uncomfortable surprises caused by huge memory usage, xz has + a built-in memory usage limiter. The default limit is 40 % of total + physical RAM. While operating systems provide ways to limit the memory + usage of processes, relying on it wasn't deemed to be flexible enough. + + When compressing, if the selected compression settings exceed the mem- + ory usage limit, the settings are automatically adjusted downwards and + a notice about this is displayed. As an exception, if the memory usage + limit is exceeded when compressing with --format=raw, an error is dis- + played and xz will exit with exit status 1. + + If source file cannot be decompressed without exceeding the memory + usage limit, an error message is displayed and the file is skipped. + Note that compressed files may contain many blocks, which may have been + compressed with different settings. Typically all blocks will have + roughly the same memory requirements, but it is possible that a block + later in the file will exceed the memory usage limit, and an error + about too low memory usage limit gets displayed after some data has + already been decompressed. + + The absolute value of the active memory usage limit can be seen near + the bottom of the output of --long-help. The default limit can be + overridden with --memory=limit. + +OPTIONS + Integer suffixes and special values + In most places where an integer argument is expected, an optional suf- + fix is supported to easily indicate large integers. There must be no + space between the integer and the suffix. + + k or kB + The integer is multiplied by 1,000 (10^3). For example, 5k or + 5kB equals 5000. + + Ki or KiB + The integer is multiplied by 1,024 (2^10). + + M or MB + The integer is multiplied by 1,000,000 (10^6). + + Mi or MiB + The integer is multiplied by 1,048,576 (2^20). + + G or GB + The integer is multiplied by 1,000,000,000 (10^9). + + Gi or GiB + The integer is multiplied by 1,073,741,824 (2^30). + + A special value max can be used to indicate the maximum integer value + supported by the option. + + Operation mode + If multiple operation mode options are given, the last one takes + effect. + + -z, --compress + Compress. This is the default operation mode when no operation + mode option is specified, and no other operation mode is implied + from the command name (for example, unxz implies --decompress). + + -d, --decompress, --uncompress + Decompress. + + -t, --test + Test the integrity of compressed files. No files are created or + removed. This option is equivalent to --decompress --stdout + except that the decompressed data is discarded instead of being + written to standard output. + + -l, --list + View information about the compressed files. No uncompressed + output is produced, and no files are created or removed. In list + mode, the program cannot read the compressed data from standard + input or from other unseekable sources. + + This feature has not been implemented yet. + + Operation modifiers + -k, --keep + Keep (don't delete) the input files. + + -f, --force + This option has several effects: + + o If the target file already exists, delete it before compress- + ing or decompressing. + + o Compress or decompress even if the input is not a regular + file, has more than one hardlink, or has setuid, setgid, or + sticky bit set. The setuid, setgid, and sticky bits are not + copied to the target file. + + o If combined with --decompress --stdout and xz doesn't recog- + nize the type of the source file, xz will copy the source + file as is to standard output. This allows using xzcat + --force like cat(1) for files that have not been compressed + with xz. Note that in future, xz might support new com- + pressed file formats, which may make xz decompress more types + of files instead of copying them as is to standard output. + --format=format can be used to restrict xz to decompress only + a single file format. + + o Allow writing compressed data to a terminal, and reading com- + pressed data from a terminal. + + -c, --stdout, --to-stdout + Write the compressed or decompressed data to standard output + instead of a file. This implies --keep. + + -S .suf, --suffix=.suf + When compressing, use .suf as the suffix for the target file + instead of .xz or .lzma. If not writing to standard output and + the source file already has the suffix .suf, a warning is dis- + played and the file is skipped. + + When decompressing, recognize also files with the suffix .suf in + addition to files with the .xz, .txz, .lzma, or .tlz suffix. If + the source file has the suffix .suf, the suffix is removed to + get the target filename. + + When compressing or decompressing raw streams (--format=raw), + the suffix must always be specified unless writing to standard + output, because there is no default suffix for raw streams. + + --files[=file] + Read the filenames to process from file; if file is omitted, + filenames are read from standard input. Filenames must be termi- + nated with the newline character. If filenames are given also as + command line arguments, they are processed before the filenames + read from file. + + --files0[=file] + This is identical to --files[=file] except that the filenames + must be terminated with the null character. + + Basic file format and compression options + -F format, --format=format + Specify the file format to compress or decompress: + + o auto: This is the default. When compressing, auto is equiva- + lent to xz. When decompressing, the format of the input file + is autodetected. Note that raw streams (created with --for- + mat=raw) cannot be autodetected. + + o xz: Compress to the .xz file format, or accept only .xz files + when decompressing. + + o lzma or alone: Compress to the legacy .lzma file format, or + accept only .lzma files when decompressing. The alternative + name alone is provided for backwards compatibility with LZMA + Utils. + + o raw: Compress or uncompress a raw stream (no headers). This + is meant for advanced users only. To decode raw streams, you + need to set not only --format=raw but also specify the filter + chain, which would normally be stored in the container format + headers. + + -C check, --check=check + Specify the type of the integrity check, which is calculated + from the uncompressed data. This option has an effect only when + compressing into the .xz format; the .lzma format doesn't sup- + port integrity checks. The integrity check (if any) is verified + when the .xz file is decompressed. + + Supported check types: + + o none: Don't calculate an integrity check at all. This is usu- + ally a bad idea. This can be useful when integrity of the + data is verified by other means anyway. + + o crc32: Calculate CRC32 using the polynomial from IEEE-802.3 + (Ethernet). + + o crc64: Calculate CRC64 using the polynomial from ECMA-182. + This is the default, since it is slightly better than CRC32 + at detecting damaged files and the speed difference is negli- + gible. + + o sha256: Calculate SHA-256. This is somewhat slower than CRC32 + and CRC64. + + Integrity of the .xz headers is always verified with CRC32. It + is not possible to change or disable it. + + -0 ... -9 + Select compression preset. If a preset level is specified multi- + ple times, the last one takes effect. + + The compression preset levels can be categorised roughly into + three categories: + + -0 ... -2 + Fast presets with relatively low memory usage. -1 and -2 + should give compression speed and ratios comparable to + bzip2 -1 and bzip2 -9, respectively. Currently -0 is not + very good (not much faster than -1 but much worse com- + pression). In future, -0 may be indicate some fast algo- + rithm instead of LZMA2. + + -3 ... -5 + Good compression ratio with low to medium memory usage. + These are significantly slower than levels 0-2. + + -6 ... -9 + Excellent compression with medium to high memory usage. + These are also slower than the lower preset levels. The + default is -6. Unless you want to maximize the compres- + sion ratio, you probably don't want a higher preset level + than -7 due to speed and memory usage. + + The exact compression settings (filter chain) used by each pre- + set may vary between xz versions. The settings may also vary + between files being compressed, if xz determines that modified + settings will probably give better compression ratio without + significantly affecting compression time or memory usage. + + Because the settings may vary, the memory usage may vary too. + The following table lists the maximum memory usage of each pre- + set level, which won't be exceeded even in future versions of + xz. + + FIXME: The table below is just a rough idea. + + Preset Compression Decompression + -0 6 MiB 1 MiB + -1 6 MiB 1 MiB + -2 10 MiB 1 MiB + -3 20 MiB 2 MiB + -4 30 MiB 3 MiB + -5 60 MiB 6 MiB + -6 100 MiB 10 MiB + -7 200 MiB 20 MiB + -8 400 MiB 40 MiB + -9 800 MiB 80 MiB + + When compressing, xz automatically adjusts the compression set- + tings downwards if the memory usage limit would be exceeded, so + it is safe to specify a high preset level even on systems that + don't have lots of RAM. + + --fast and --best + These are somewhat misleading aliases for -0 and -9, respec- + tively. These are provided only for backwards compatibility + with LZMA Utils. Avoid using these options. + + Especially the name of --best is misleading, because the defini- + tion of best depends on the input data, and that usually people + don't want the very best compression ratio anyway, because it + would be very slow. + + -e, --extreme + Modify the compression preset (-0 ... -9) so that a little bit + better compression ratio can be achieved without increasing mem- + ory usage of the compressor or decompressor (exception: compres- + sor memory usage may increase a little with presets -0 ... -2). + The downside is that the compression time will increase dramati- + cally (it can easily double). + + -M limit, --memory=limit + Set the memory usage limit. If this option is specied multiple + times, the last one takes effect. The limit can be specified in + multiple ways: + + o The limit can be an absolute value in bytes. Using an integer + suffix like MiB can be useful. Example: --memory=80MiB + + o The limit can be specified as a percentage of physical RAM. + Example: --memory=70% + + o The limit can be reset back to its default value (currently + 40 % of physical RAM) by setting it to 0. + + o The memory usage limiting can be effectively disabled by set- + ting limit to max. This isn't recommended. It's usually bet- + ter to use, for example, --memory=90%. + + The current limit can be seen near the bottom of the output of + the --long-help option. + + -T threads, --threads=threads + Specify the maximum number of worker threads to use. The default + is the number of available CPU cores. You can see the current + value of threads near the end of the output of the --long-help + option. + + The actual number of worker threads can be less than threads if + using more threads would exceed the memory usage limit. In + addition to CPU-intensive worker threads, xz may use a few aux- + iliary threads, which don't use a lot of CPU time. + + Multithreaded compression and decompression are not implemented + yet, so this option has no effect for now. + + Custom compressor filter chains + A custom filter chain allows specifying the compression settings in + detail instead of relying on the settings associated to the preset lev- + els. When a custom filter chain is specified, the compression preset + level options (-0 ... -9 and --extreme) are silently ignored. + + A filter chain is comparable to piping on the UN*X command line. When + compressing, the uncompressed input goes to the first filter, whose + output goes to the next filter (if any). The output of the last filter + gets written to the compressed file. The maximum number of filters in + the chain is four, but typically a filter chain has only one or two + filters. + + Many filters have limitations where they can be in the filter chain: + some filters can work only as the last filter in the chain, some only + as a non-last filter, and some work in any position in the chain. + Depending on the filter, this limitation is either inherent to the fil- + ter design or exists to prevent security issues. + + A custom filter chain is specified by using one or more filter options + in the order they are wanted in the filter chain. That is, the order of + filter options is significant! When decoding raw streams (--for- + mat=raw), the filter chain is specified in the same order as it was + specified when compressing. + + Filters take filter-specific options as a comma-separated list. Extra + commas in options are ignored. Every option has a default value, so you + need to specify only those you want to change. + + --lzma1[=options], --lzma2[=options] + Add LZMA1 or LZMA2 filter to the filter chain. These filter can + be used only as the last filter in the chain. + + LZMA1 is a legacy filter, which is supported almost solely due + to the legacy .lzma file format, which supports only LZMA1. + LZMA2 is an updated version of LZMA1 to fix some practical + issues of LZMA1. The .xz format uses LZMA2, and doesn't support + LZMA1 at all. Compression speed and ratios of LZMA1 and LZMA2 + are practically the same. + + LZMA1 and LZMA2 share the same set of options: + + preset=preset + Reset all LZMA1 or LZMA2 options to preset. Preset con- + sist of an integer, which may be followed by single-let- + ter preset modifiers. The integer can be from 0 to 9, + matching the command line options -0 ... -9. The only + supported modifier is currently e, which matches + --extreme. + + The default preset is 6, from which the default values + for the rest of the LZMA1 or LZMA2 options are taken. + + dict=size + Dictionary (history buffer) size indicates how many bytes + of the recently processed uncompressed data is kept in + memory. One method to reduce size of the uncompressed + data is to store distance-length pairs, which indicate + what data to repeat from the dictionary buffer. The big- + ger the dictionary, the better the compression ratio usu- + ally is, but dictionaries bigger than the uncompressed + data are waste of RAM. + + Typical dictionary size is from 64 KiB to 64 MiB. The + minimum is 4 KiB. The maximum for compression is cur- + rently 1.5 GiB. The decompressor already supports dictio- + naries up to one byte less than 4 GiB, which is the maxi- + mum for LZMA1 and LZMA2 stream formats. + + Dictionary size has the biggest effect on compression + ratio. Dictionary size and match finder together deter- + mine the memory usage of the LZMA1 or LZMA2 encoder. The + same dictionary size is required for decompressing that + was used when compressing, thus the memory usage of the + decoder is determined by the dictionary size used when + compressing. + + lc=lc Specify the number of literal context bits. The minimum + is 0 and the maximum is 4; the default is 3. In addi- + tion, the sum of lc and lp must not exceed 4. + + lp=lp Specify the number of literal position bits. The minimum + is 0 and the maximum is 4; the default is 0. + + pb=pb Specify the number of position bits. The minimum is 0 and + the maximum is 4; the default is 2. + + mode=mode + Compression mode specifies the function used to analyze + the data produced by the match finder. Supported modes + are fast and normal. The default is fast for presets 0-2 + and normal for presets 3-9. + + mf=mf Match finder has a major effect on encoder speed, memory + usage, and compression ratio. Usually Hash Chain match + finders are faster than Binary Tree match finders. Hash + Chains are usually used together with mode=fast and + Binary Trees with mode=normal. The memory usage formulas + are only rough estimates, which are closest to reality + when dict is a power of two. + + hc3 Hash Chain with 2- and 3-byte hashing + Minimum value for nice: 3 + Memory usage: dict * 7.5 (if dict <= 16 MiB); + dict * 5.5 + 64 MiB (if dict > 16 MiB) + + hc4 Hash Chain with 2-, 3-, and 4-byte hashing + Minimum value for nice: 4 + Memory usage: dict * 7.5 + + bt2 Binary Tree with 2-byte hashing + Minimum value for nice: 2 + Memory usage: dict * 9.5 + + bt3 Binary Tree with 2- and 3-byte hashing + Minimum value for nice: 3 + Memory usage: dict * 11.5 (if dict <= 16 MiB); + dict * 9.5 + 64 MiB (if dict > 16 MiB) + + bt4 Binary Tree with 2-, 3-, and 4-byte hashing + Minimum value for nice: 4 + Memory usage: dict * 11.5 + + nice=nice + Specify what is considered to be a nice length for a + match. Once a match of at least nice bytes is found, the + algorithm stops looking for possibly better matches. + + nice can be 2-273 bytes. Higher values tend to give bet- + ter compression ratio at expense of speed. The default + depends on the preset level. + + depth=depth + Specify the maximum search depth in the match finder. The + default is the special value 0, which makes the compres- + sor determine a reasonable depth from mf and nice. + + Using very high values for depth can make the encoder + extremely slow with carefully crafted files. Avoid set- + ting the depth over 1000 unless you are prepared to + interrupt the compression in case it is taking too long. + + When decoding raw streams (--format=raw), LZMA2 needs only the + value of dict. LZMA1 needs also lc, lp, and pb. + + --x86[=options] + + --powerpc[=options] + + --ia64[=options] + + --arm[=options] + + --armthumb[=options] + + --sparc[=options] + Add a branch/call/jump (BCJ) filter to the filter chain. These + filters can be used only as non-last filter in the filter chain. + + A BCJ filter converts relative addresses in the machine code to + their absolute counterparts. This doesn't change the size of the + data, but it increases redundancy, which allows e.g. LZMA2 to + get better compression ratio. + + The BCJ filters are always reversible, so using a BCJ filter for + wrong type of data doesn't cause any data loss. However, apply- + ing a BCJ filter for wrong type of data is a bad idea, because + it tends to make the compression ratio worse. + + Different instruction sets have have different alignment: + + Filter Alignment Notes + x86 1 32-bit and 64-bit x86 + PowerPC 4 Big endian only + ARM 4 Little endian only + ARM-Thumb 2 Little endian only + IA-64 16 Big or little endian + SPARC 4 Big or little endian + + Since the BCJ-filtered data is usually compressed with LZMA2, + the compression ratio may be improved slightly if the LZMA2 + options are set to match the alignment of the selected BCJ fil- + ter. For example, with the IA-64 filter, it's good to set pb=4 + with LZMA2 (2^4=16). The x86 filter is an exception; it's usu- + ally good to stick to LZMA2's default four-byte alignment when + compressing x86 executables. + + All BCJ filters support the same options: + + start=offset + Specify the start offset that is used when converting + between relative and absolute addresses. The offset must + be a multiple of the alignment of the filter (see the ta- + ble above). The default is zero. In practice, the + default is good; specifying a custom offset is almost + never useful. + + Specifying a non-zero start offset is probably useful + only if the executable has multiple sections, and there + are many cross-section jumps or calls. Applying a BCJ + filter separately for each section with proper start off- + set and then compressing the result as a single chunk may + give some improvement in compression ratio compared to + applying the BCJ filter with the default offset for the + whole executable. + + --delta[=options] + Add Delta filter to the filter chain. The Delta filter can be + used only as non-last filter in the filter chain. + + Currently only simple byte-wise delta calculation is supported. + It can be useful when compressing e.g. uncompressed bitmap + images or uncompressed PCM audio. However, special purpose algo- + rithms may give significantly better results than Delta + LZMA2. + This is true especially with audio, which compresses faster and + better e.g. with FLAC. + + Supported options: + + dist=distance + Specify the distance of the delta calculation as bytes. + distance must be 1-256. The default is 1. + + For example, with dist=2 and eight-byte input A1 B1 A2 B3 + A3 B5 A4 B7, the output will be A1 B1 01 02 01 02 01 02. + + Other options + -q, --quiet + Suppress warnings and notices. Specify this twice to suppress + errors too. This option has no effect on the exit status. That + is, even if a warning was suppressed, the exit status to indi- + cate a warning is still used. + + -v, --verbose + Be verbose. If standard error is connected to a terminal, xz + will display a progress indicator. Specifying --verbose twice + will give even more verbose output (useful mostly for debug- + ging). + + -Q, --no-warn + Don't set the exit status to 2 even if a condition worth a warn- + ing was detected. This option doesn't affect the verbosity + level, thus both --quiet and --no-warn have to be used to not + display warnings and to not alter the exit status. + + -h, --help + Display a help message describing the most commonly used + options, and exit successfully. + + -H, --long-help + Display a help message describing all features of xz, and exit + successfully + + -V, --version + Display the version number of xz and liblzma. + +EXIT STATUS + 0 All is good. + + 1 An error occurred. + + 2 Something worth a warning occurred, but no actual errors + occurred. + + Notices (not warnings or errors) printed on standard error don't affect + the exit status. + +ENVIRONMENT + XZ_OPT A space-separated list of options is parsed from XZ_OPT before + parsing the options given on the command line. Note that only + options are parsed from XZ_OPT; all non-options are silently + ignored. Parsing is done with getopt_long(3) which is used also + for the command line arguments. + +LZMA UTILS COMPATIBILITY + The command line syntax of xz is practically a superset of lzma, + unlzma, and lzcat as found from LZMA Utils 4.32.x. In most cases, it is + possible to replace LZMA Utils with XZ Utils without breaking existing + scripts. There are some incompatibilities though, which may sometimes + cause problems. + + Compression preset levels + The numbering of the compression level presets is not identical in xz + and LZMA Utils. The most important difference is how dictionary sizes + are mapped to different presets. Dictionary size is roughly equal to + the decompressor memory usage. + + Level xz LZMA Utils + -1 64 KiB 64 KiB + -2 512 KiB 1 MiB + -3 1 MiB 512 KiB + -4 2 MiB 1 MiB + -5 4 MiB 2 MiB + -6 8 MiB 4 MiB + -7 16 MiB 8 MiB + -8 32 MiB 16 MiB + -9 64 MiB 32 MiB + + The dictionary size differences affect the compressor memory usage too, + but there are some other differences between LZMA Utils and XZ Utils, + which make the difference even bigger: + + Level xz LZMA Utils 4.32.x + -1 2 MiB 2 MiB + -2 5 MiB 12 MiB + -3 13 MiB 12 MiB + -4 25 MiB 16 MiB + -5 48 MiB 26 MiB + -6 94 MiB 45 MiB + -7 186 MiB 83 MiB + -8 370 MiB 159 MiB + -9 674 MiB 311 MiB + + The default preset level in LZMA Utils is -7 while in XZ Utils it is + -6, so both use 8 MiB dictionary by default. + + Streamed vs. non-streamed .lzma files + Uncompressed size of the file can be stored in the .lzma header. LZMA + Utils does that when compressing regular files. The alternative is to + mark that uncompressed size is unknown and use end of payload marker to + indicate where the decompressor should stop. LZMA Utils uses this + method when uncompressed size isn't known, which is the case for exam- + ple in pipes. + + xz supports decompressing .lzma files with or without end of payload + marker, but all .lzma files created by xz will use end of payload + marker and have uncompressed size marked as unknown in the .lzma + header. This may be a problem in some (uncommon) situations. For exam- + ple, a .lzma decompressor in an embedded device might work only with + files that have known uncompressed size. If you hit this problem, you + need to use LZMA Utils or LZMA SDK to create .lzma files with known + uncompressed size. + + Unsupported .lzma files + The .lzma format allows lc values up to 8, and lp values up to 4. LZMA + Utils can decompress files with any lc and lp, but always creates files + with lc=3 and lp=0. Creating files with other lc and lp is possible + with xz and with LZMA SDK. + + The implementation of the LZMA1 filter in liblzma requires that the sum + of lc and lp must not exceed 4. Thus, .lzma files which exceed this + limitation, cannot be decompressed with xz. + + LZMA Utils creates only .lzma files which have dictionary size of 2^n + (a power of 2), but accepts files with any dictionary size. liblzma + accepts only .lzma files which have dictionary size of 2^n or 2^n + + 2^(n-1). This is to decrease false positives when autodetecting .lzma + files. + + These limitations shouldn't be a problem in practice, since practically + all .lzma files have been compressed with settings that liblzma will + accept. + + Trailing garbage + When decompressing, LZMA Utils silently ignore everything after the + first .lzma stream. In most situations, this is a bug. This also means + that LZMA Utils don't support decompressing concatenated .lzma files. + + If there is data left after the first .lzma stream, xz considers the + file to be corrupt. This may break obscure scripts which have assumed + that trailing garbage is ignored. + +NOTES + Compressed output may vary + The exact compressed output produced from the same uncompressed input + file may vary between XZ Utils versions even if compression options are + identical. This is because the encoder can be improved (faster or bet- + ter compression) without affecting the file format. The output can vary + even between different builds of the same XZ Utils version, if differ- + ent build options are used or if the endianness of the hardware is dif- + ferent for different builds. + + The above means that implementing --rsyncable to create rsyncable .xz + files is not going to happen without freezing a part of the encoder + implementation, which can then be used with --rsyncable. + + Embedded .xz decompressors + Embedded .xz decompressor implementations like XZ Embedded don't neces- + sarily support files created with check types other than none and + crc32. Since the default is --check=crc64, you must use --check=none + or --check=crc32 when creating files for embedded systems. + + Outside embedded systems, all .xz format decompressors support all the + check types, or at least are able to decompress the file without veri- + fying the integrity check if the particular check is not supported. + + XZ Embedded supports BCJ filters, but only with the default start off- + set. + +SEE ALSO + xzdec(1), gzip(1), bzip2(1) + + XZ Utils: <http://tukaani.org/xz/> + XZ Embedded: <http://tukaani.org/xz/embedded.html> + LZMA SDK: <http://7-zip.org/sdk.html> + + + +Tukaani 2009-08-27 XZ(1) diff --git a/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzdec.txt b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzdec.txt new file mode 100644 index 00000000..ee2b820a --- /dev/null +++ b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzdec.txt @@ -0,0 +1,95 @@ +XZDEC(1) XZ Utils XZDEC(1) + + + +NAME + xzdec, lzmadec - Small .xz and .lzma decompressors + +SYNOPSIS + xzdec [option]... [file]... + lzmadec [option]... [file]... + +DESCRIPTION + xzdec is a liblzma-based decompression-only tool for .xz (and only .xz) + files. xzdec is intended to work as a drop-in replacement for xz(1) in + the most common situations where a script has been written to use xz + --decompress --stdout (and possibly a few other commonly used options) + to decompress .xz files. lzmadec is identical to xzdec except that + lzmadec supports .lzma files instead of .xz files. + + To reduce the size of the executable, xzdec doesn't support multi- + threading or localization, and doesn't read options from XZ_OPT envi- + ronment variable. xzdec doesn't support displaying intermediate + progress information: sending SIGINFO to xzdec does nothing, but send- + ing SIGUSR1 terminates the process instead of displaying progress + information. + +OPTIONS + -d, --decompress, --uncompress + Ignored for xz(1) compatibility. xzdec supports only decompres- + sion. + + -k, --keep + Ignored for xz(1) compatibility. xzdec never creates or removes + any files. + + -c, --stdout, --to-stdout + Ignored for xz(1) compatibility. xzdec always writes the decom- + pressed data to standard output. + + -M limit, --memory=limit + Set the memory usage limit. If this option is specified multi- + ple times, the last one takes effect. The limit can be specified + in multiple ways: + + o The limit can be an absolute value in bytes. Using an integer + suffix like MiB can be useful. Example: --memory=80MiB + + o The limit can be specified as a percentage of physical RAM. + Example: --memory=70% + + o The limit can be reset back to its default value (currently + 40 % of physical RAM) by setting it to 0. + + o The memory usage limiting can be effectively disabled by set- + ting limit to max. This isn't recommended. It's usually bet- + ter to use, for example, --memory=90%. + + The current limit can be seen near the bottom of the output of + the --help option. + + -q, --quiet + Specifying this once does nothing since xzdec never displays any + warnings or notices. Specify this twice to suppress errors. + + -Q, --no-warn + Ignored for xz(1) compatibility. xzdec never uses the exit sta- + tus 2. + + -h, --help + Display a help message and exit successfully. + + -V, --version + Display the version number of xzdec and liblzma. + +EXIT STATUS + 0 All was good. + + 1 An error occurred. + + xzdec doesn't have any warning messages like xz(1) has, thus the exit + status 2 is not used by xzdec. + +NOTES + xzdec and lzmadec are not really that small. The size can be reduced + further by dropping features from liblzma at compile time, but that + shouldn't usually be done for executables distributed in typical non- + embedded operating system distributions. If you need a truly small .xz + decompressor, consider using XZ Embedded. + +SEE ALSO + xz(1) + + + +Tukaani 2009-06-04 XZDEC(1) diff --git a/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzdiff.txt b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzdiff.txt new file mode 100644 index 00000000..f64568f2 --- /dev/null +++ b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzdiff.txt @@ -0,0 +1,36 @@ +XZDIFF(1) XZ Utils XZDIFF(1) + + + +NAME + xzcmp, xzdiff, lzcmp, lzdiff - compare compressed files + +SYNOPSIS + xzcmp [cmp_options] file1 [file2] + xzdiff [diff_options] file1 [file2] + lzcmp [cmp_options] file1 [file2] + lzdiff [diff_options] file1 [file2] + +DESCRIPTION + xzcmp and xdiff invoke cmp(1) or diff(1) on files compressed with + xz(1), lzma(1), gzip(1), or bzip2(1). All options specified are passed + directly to cmp or diff. If only one file is specified, then the files + compared are file1 (which must have a suffix of a supported compression + format) and file1 from which the compression format suffix has been + stripped. If two files are specified, then they are uncompressed if + necessary and fed to cmp(1) or diff(1). The exit status from cmp or + diff is preserved. + + The names lzcmp and lzdiff are provided for backward compatibility with + LZMA Utils. + +SEE ALSO + cmp(1), diff(1), xz(1), gzip(1), bzip2(1), zdiff(1) + +BUGS + Messages from the cmp(1) or diff(1) programs refer to temporary file- + names instead of those specified. + + + +Tukaani 2009-07-05 XZDIFF(1) diff --git a/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzgrep.txt b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzgrep.txt new file mode 100644 index 00000000..7f665bce --- /dev/null +++ b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzgrep.txt @@ -0,0 +1,39 @@ +XZGREP(1) XZ Utils XZGREP(1) + + + +NAME + xzgrep - search compressed files for a regular expression + +SYNOPSIS + xzgrep [grep_options] [-e] pattern file... + xzegrep ... + xzfgrep ... + lzgrep ... + lzegrep ... + lzfgrep ... + +DESCRIPTION + xzgrep invokes grep(1) on files which may be either uncompressed or + compressed with xz(1), lzma(1), gzip(1), or bzip2(1). All options + specified are passed directly to grep(1). + + If no file is specified, then the standard input is decompressed if + necessary and fed to grep(1). When reading from standard input, + gzip(1) and bzip2(1) compressed files are not supported. + + If xzgrep is invoked as xzegrep or xzfgrep then egrep(1) or fgrep(1) is + used instead of grep(1). The same applies to names lzgrep, lzegrep, + and lzfgrep, which are provided for backward compatibility with LZMA + Utils. + +ENVIRONMENT + GREP If the GREP environment variable is set, xzgrep uses it instead + of grep(1), egrep(1), or fgrep(1). + +SEE ALSO + grep(1), xz(1), gzip(1), bzip2(1), zgrep(1) + + + +Tukaani 2009-07-05 XZGREP(1) diff --git a/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzless.txt b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzless.txt new file mode 100644 index 00000000..2f3dc9fe --- /dev/null +++ b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzless.txt @@ -0,0 +1,40 @@ +XZLESS(1) XZ Utils XZLESS(1) + + + +NAME + xzless, lzless - view xz or lzma compressed (text) files + +SYNOPSIS + xzless [file...] + lzless [file...] + +DESCRIPTION + xzless is a filter that displays pagefulls of uncompressed text from + compressed file(s) to a terminal. It works on files compressed with + xz(1) or lzma(1). If no files are given, xzless reads from standard + input. + + xzless uses less(1) as its only pager. Unlike xzmore, the choice of + pagers is not alterable by an environment variable. Commands are based + on both more(1) and vi(1), and allow back and forth movement and + searching. See the less(1) manual for more information. + + The command named lzless is provided for backward compatibility with + LZMA Utils. + +ENVIRONMENT + LESSMETACHARS + A list of characters special to the shell. Set by xzless unless + it is already set in the environment. + + LESSOPEN + Set to a command line to invoke the xz(1) decompressor for pre- + processing the input files to less(1). + +SEE ALSO + less(1), xz(1), xzmore(1), zless(1) + + + +Tukaani 2009-07-05 XZLESS(1) diff --git a/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzmore.txt b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzmore.txt new file mode 100644 index 00000000..6f6cfe93 --- /dev/null +++ b/storage/tokudb/PerconaFT/third_party/xz-4.999.9beta/doc/man/txt/xzmore.txt @@ -0,0 +1,34 @@ +XZMORE(1) XZ Utils XZMORE(1) + + + +NAME + xzmore, lzmore - view xz or lzma compressed (text) files + +SYNOPSIS + xzmore [filename ...] + lzmore [filename ...] + +DESCRIPTION + xzmore is a filter which allows examination of xz(1) or lzma(1) com- + pressed text files one screenful at a time on a soft-copy terminal. + + To use a pager other than the default more, set environment variable + PAGER to the name of the desired program. The name lzmore is provided + for backward compatibility with LZMA Utils. + + e or q When the prompt --More--(Next file: file) is printed, this com- + mand causes xzmore to exit. + + s When the prompt --More--(Next file: file) is printed, this com- + mand causes xzmore to skip the next file and continue. + + For list of keyboard commands supported while actually viewing the con- + tent of a file, refer to manual of the pager you use, usually more(1). + +SEE ALSO + more(1), xz(1), xzless(1), zmore(1) + + + +Tukaani 2009-07-05 XZMORE(1) |