3

The following script

mkdir test && cd test
mkdir files
touch files/{1,2,3}
tar --create --file "test.lzma" files/{1,2,3} --auto-compress
mkdir extracted_files
tar --extract --file "test.lzma" --directory extracted_files --auto-compress

produces the following error:

tar: This does not look like a tar archive

but actually tar+compress and uncompress+untar do happen (files are in place). Why is this happening? Is it some kind of bug in tar?

On my system:

xz --version
 xz (XZ Utils) 5.2.7
 liblzma 5.2.7
tar --version
 tar (GNU tar) 1.34
file test/test.lzma
 test/test.lzma: LZMA compressed data, streamed
ls test/extracted_files/
 files

You can also reproduce it in https://replit.com/languages/bash (with xz (XZ Utils) 5.2.2 and tar (GNU tar) 1.34). But not in https://www.onlinegdb.com/online_bash_shell (with xz (XZ Utils) 5.2.4 and tar (GNU tar) 1.30).

cppbest
  • 93
  • 5
  • 1
    here with XZ 5.2.5 and tar 1.34 the .lzma file format is XZ instead of LZMA and "it works". So I can reproduce it instead by using `-Ilzma` instead of `--auto-compress` at creation time. Then it fails at extraction time with `--auto-compress`. Of course it works if I force `-Ilzma` at extraction time. (note: `lzma` is an alias of `xz` with changed behavior). – A.B Oct 21 '22 at 14:58

1 Answers1

0

Fixed in upstream. Check out https://savannah.gnu.org/bugs/index.php?63250.

@Sergey Poznyakoff <gray>:

The "This does not look like a tar archive" is not an error, but a warning. It is produced, in particular, when tar is unable to determine file format by signature and file size is less than tar block size. When the signature recognition fails, tar tries to determine file format by its suffix. In this case, it succeeded and extracted the files.

I have installed the following fix to recognized LZMA files produced by xz:

http://git.savannah.gnu.org/cgit/tar.git/commit/?id=02f9af1b8df67e55ceb19ea1465d210a2fa1f02c

PS: The --auto-compress option is not needed when extracting.

cppbest
  • 93
  • 5