Browsing French translation

31.

Once the target file has been successfully closed, the source I<file> is removed unless B<--keep> was specified. The source I<file> is never removed if the output is written to standard output.

35.

Especially users of older systems may find the possibility of very large memory usage annoying. To prevent uncomfortable surprises, B<xz> has a built-in memory usage limiter, which is disabled by default. While some operating systems provide ways to limit the memory usage of processes, relying on it wasn't deemed to be flexible enough (e.g. using B<ulimit>(1) to limit virtual memory tends to cripple B<mmap>(2)).

36.

The memory usage limiter can be enabled with the command line option B<--memlimit=>I<limit>. Often it is more convenient to enable the limiter by default by setting the environment variable B<XZ_DEFAULTS>, e.g.\& B<XZ_DEFAULTS=--memlimit=150MiB>. It is possible to set the limits separately for compression and decompression by using B<--memlimit-compress=>I<limit> and B<--memlimit-decompress=>I<limit>. Using these two options outside B<XZ_DEFAULTS> is rarely useful because a single run of B<xz> cannot do both compression and decompression and B<--memlimit=>I<limit> (or B<-M> I<limit>) is shorter to type on the command line.

37.

If the specified memory usage limit is exceeded when decompressing, B<xz> will display an error and decompressing the file will fail. If the limit is exceeded when compressing, B<xz> will try to scale the settings down so that the limit is no longer exceeded (except when using B<--format=raw> or B<--no-adjust>). This way the operation won't fail unless the limit is very small. The scaling of the settings is done in steps that don't match the compression level presets, e.g. if the limit is only slightly less than the amount required for B<xz -9>, the settings will be scaled down only a little, not all the way down to B<xz -8>.

40.

It is possible to insert padding between the concatenated parts or after the last part. The padding must consist of null bytes and the size of the padding must be a multiple of four bytes. This can be useful e.g. if the B<.xz> file is stored on a medium that measures file sizes in 512-byte blocks.

62.

The default listing shows basic information about I<files>, one file per line. To get more detailed information, use also the B<--verbose> option. For even more information, use B<--verbose> twice, but note that this may be slow, because getting all the extra information requires many seeks. The width of verbose output exceeds 80 characters, so piping the output to e.g.\& B<less\ -S> may be convenient if the terminal isn't wide enough.

122.

Good to very good compression while keeping decompressor memory usage reasonable even for old systems. B<-6> is the default, which is usually a good choice e.g. for distributing files that need to be decompressible even on systems with only 16\ MiB RAM. (B<-5e> or B<-6e> may be worth considering too. See B<--extreme>.)

196.

In multi-threaded mode about three times I<size> bytes will be allocated in each thread for buffering input and output. The default I<size> is three times the LZMA2 dictionary size or 1 MiB, whichever is more. Typically a good value is 2-4 times the size of the LZMA2 dictionary or at least 1 MiB. Using I<size> less than the LZMA2 dictionary size is waste of RAM because then the LZMA2 dictionary buffer will never get fully used. The sizes of the blocks are stored in the block headers, which a future version of B<xz> will use for multi-threaded decompression.

216.

For 32-bit B<xz> there is a special case: if the I<limit> would be over B<4020\ MiB>, the I<limit> is set to B<4020\ MiB>. (The values B<0> and B<max> aren't affected by this. A similar feature doesn't exist for decompression.) This can be helpful when a 32-bit executable has access to 4\ GiB address space while hopefully doing no harm in other situations.

221.

This is equivalent to specifying B<--memlimit-compress=>I<limit >B<--memlimit-decompress=>I<limit>.