Vincent Lefevre (HE12025-08-09):
> With tar utilities that support xz (like GNU tar), not using "xz -d"
> could be more efficient as "xz -d" will uncompress the whole file
> while this may not be necessary:
>
> tar tf file.tar.xz
>
> is sufficient. This may allow one to skip xz blocks if the archive
> contains big files. That said, I don't know whether GNU tar has
> such an optimization.
GNU tar not have any such optimization, that can be observed easily
with:
~ $ ldd =tar
linux-vdso.so.1 (0x0000147694d94000)
libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x0000147694cee000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x0000147694cba000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000147694ac4000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0
(0x0000147694a15000)
/lib64/ld-linux-x86-64.so.2 (0x0000147694d96000)
… notice the absence of any decompression library, especially lzma.
And:
~ $ PATH=/usr/bin strace -f -e execve tar -xJ < /dev/null
execve("/usr/bin/tar", ["tar", "-xJ"], 0x7ffe43f3e300 /* 37 vars */) = 0
strace: Process 4164248 attached
strace: Process 4164249 attached
[pid 4164249] execve("/usr/bin/xz", ["xz", "-d"], 0x7fff568c49a0 /* 37 vars */)
= 0
… notice that it is just forking and executing a xz process.
Moreover, such an optimization would be mostly useless, as most xz files
out there are made of a single block with sizes not specified.
Side notes:
libpcre2-8.so.0 comes because of libselinux.so.1, which is a little
worrying as PCRE has been known to have security issues of its own.
Forking a decompression program is not a bad way to do it. With perl,
forking gunzip or unxz is a lot faster than IO::Uncompress::*. Also,
forking lets the decompression happen simultaneously without all the
hassle of synchronizing threads.
Regards,
--
Nicolas George
