On 2025-08-10 10:10:38 +0200, Nicolas George wrote: > Vincent Lefevre (HE12025-08-10): > > Yes, an example: > > > > qaa% ls -l PROGRAMME-FFC-2024.pdf > > -rw-r--r-- 1 vinc17 vinc17 40991563 2024-11-11 02:18:14 > > PROGRAMME-FFC-2024.pdf > > qaa% xz -k PROGRAMME-FFC-2024.pdf > > qaa% xz -lv PROGRAMME-FFC-2024.pdf.xz > > PROGRAMME-FFC-2024.pdf.xz (1/1) > > Streams: 1 > > Blocks: 2 > > Compressed size: 38.7 MiB (40530824 B) > > Uncompressed size: 39.1 MiB (40991563 B) > > Ratio: 0.989 > > Check: CRC64 > > Stream Padding: 0 B > > Streams: > > Stream Blocks CompOffset UncompOffset CompSize > > UncompSize Ratio Check Padding > > 1 2 0 0 40530824 > > 40991563 0.989 CRC64 0 > > Blocks: > > Stream Block CompOffset UncompOffset TotalSize > > UncompSize Ratio Check > > 1 1 12 0 24961828 > > 25165824 0.992 CRC64 > > 1 2 24961840 25165824 15568948 > > 15825739 0.984 CRC64 > > I stand corrected, but I will argue that this is a non-idiomatic use of > xz, especially for tar archives: they are almost always compressed on > the fly, not stored into a file and then compressed.
Since I was using the default for xz, this doesn't change anything (see my test in an earlier message). But even if the external xz is used by tar, the options could be changed if need be with XZ_DEFAULTS (change by the user) or XZ_OPT (change by tar itself). This is documented in the xz(1) man page, with an example using "tar". -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
