Browsing Mapudungun translation

28.

The operation mode is set to compress and the I<file> already has a suffix of the target file format (B<.xz> or B<.txz> when compressing to the B<.xz> format, and B<.lzma> or B<.tlz> when compressing to the B<.lzma> format).

29.

The operation mode is set to decompress and the I<file> doesn't have a suffix of any of the supported file formats (B<.xz>, B<.txz>, B<.lzma>, B<.tlz>, or B<.lz>).

30.

After successfully compressing or decompressing the I<file>, B<xz> copies the owner, group, permissions, access time, and modification time from the source I<file> to the target file. If copying the group fails, the permissions are modified so that the target file doesn't become accessible to users who didn't have permission to access the source I<file>. B<xz> doesn't support copying other metadata like access control lists or extended attributes yet.

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 or if an error occurs.

32.

Sending B<SIGINFO> or B<SIGUSR1> to the B<xz> process makes it print progress information to standard error. This has only limited use since when standard error is a terminal, using B<--verbose> will display an automatically updating progress indicator.

33.

Memory usage

34.

The memory usage of B<xz> varies from a few hundred kilobytes to several gigabytes depending on the compression settings. The settings used when compressing a file determine the memory requirements of the decompressor. Typically the decompressor needs 5\ % to 20\ % of the amount of memory that the compressor needed when creating the file. For example, decompressing a file created with B<xz -9> currently requires 65\ MiB of memory. Still, it is possible to have B<.xz> files that require several gigabytes of memory to decompress.

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 (for example, 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>, for example, 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, for example, 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>.