Cannot extract tar.gz

[smiddy]

Expected behaviour

Having an archive archive.tar.gz and extract it.

Actual behaviour

I get the error:

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

Steps to reproduce the behaviour

The error does not occur on all tar.gz. files. E.g., when I create an archive with engrampa, I can extract it afterwards.
The archive itself is o.k, I extracted it on a CentOS 7 mashine with a different program.

MATE general version

1.20

Package version

1.20

Linux Distribution

Xubuntu 18.04 64bit

Link to downstream report of your Distribution

[ghost]

So the file probably really is not a tar format.

[vkareh]

@smiddy - do you have the file in question so that we can test it?

[smiddy]

Unfortunately, there is some sensitive data in the archive. I think i produced it once on my CentOs mashine as well.

@vkareh should I try to produce a tar.gz archive which resultstin the error?

[vkareh]

@smiddy, yes please. That would be very helpful. Any file that fails like that would work for me, just make sure that it only fails in engrampa (file-roller and tar xvfz should be able to open it normally) so that I can reproduce the issue. Thanks!

[ghost]

This error occurs when the file is not the same format as extension supposed. Just check it with file

The error should be reproducible with the attached file!
README.tar.gz

[lukefromdc]

Tar cannot open this file, I got

luke@ubuntu:~/Desktop$ tar -xf '/home/luke/Desktop/README' 
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

So either the file is bad(most likely) or there is a problem in tar itself. I don't know if there is some new kind of tar archive that is not supported by even the tar version shipped now in Debian Unstable, or if there are some random problems where the problem archives are first being made.

[vkareh]

I would say that if tar cannot open the file, it's probably beyond us to fix it... (just tried it and get the same issue - no matter which flags I pass on to tar, it just doesn't work, so this file is corrupted).

@cranes-bill - how did you create this file?

[vkareh]

okay, I renamed this file to README.zip and it opened just fine. This means that engrampa is using the mimetype to determine the archive backend, rather than the magic number.

[ghost]

Well, i know my English is terrible, sorry about that, but what is not clear here!? The file just is not a TAR. It was intended to produce this error, in order to illustrate the error is always reproducible when the file is wrongly recognized.
However, this is some kind of bug, because Engrampa should uses libmagic in order to determine the file type, but not the file extension. We are not on Windows ;-D

[lukefromdc]

Confirmed: if named readme.zip it opens. I have engrampa built with libmagic support (note that it can also be built without it)

[vkareh]

I also use the --enable-magic flag, so I have libmagic support too - which means this might be a bug after all... however, we still don't know about @smiddy's scenario - is the original file in question not a tar? How was it created?

[ghost]

So the problem is only when the file has .tar in the name, because this file is gzip and since Engrampa can opens it when is renamed to ZIP, it properly uses libmagic
So the problem here is: why Engrampa does not use libmagic when the file has .tar in it's name...

[vkareh]

@cranes-bill: not entirely accurate, I think... if I rename the file as README.foo or README.bz2 it still doesn't work. However, using README.7z or even README.tar.7z works fine too - so something in the file detection is getting confused between the mimetype and the file signature - not yet clear what the pattern is...

[ghost]

Actually i added some "debug" messages and noticed that it uses Libmagic only if extension is not known, otherwise it determines mime type from the file extension, which is sucks :-(

[smiddy]

I could reproduce the error with both archives:

/home/ppp/Downloads> tar -xf ./README.tar.gz 
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors 

Same error for my own archive.

Interesting: When I use File Roller 3.22.3 I can open my archive, but not your README.tar.gz

When I rename the archive to README.zip, I cannot open it with Engrampa or File Roller

[ghost]

@smiddy What is the output from the following command:
file --mime-type --keep-going --brief /path/to/your/own/archive.tar.gz

[smiddy]

I had to download the file from our server again (new copy)

For file --mime-type --keep-going --brief I get application/x-gzip, but this time I can open it with engrampa...

[ghost]

So the file for sure is gzip and the situation is as i supposed. If you rename it to *.gz, you should be able to open it with Engrampa.

By the way, i found a way how to always use Libmagic and will apply it for myself, until somebody consider fixing.

[vkareh]

@cranes-bill - how do you force engrampa to always use libmagic?

[ghost]

@vkareh Not sure that is the right solution, but works perfect to me:

 src/fr-archive.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/fr-archive.c b/src/fr-archive.c
index fcb4c82..0993d0c 100644
--- a/src/fr-archive.c
+++ b/src/fr-archive.c
@@ -1146,7 +1146,11 @@ load_local_archive (FrArchive  *archive,
 
 	old_command = archive->command;
 
+#if ENABLE_MAGIC
+	mime_type = get_mime_type_from_magic_numbers (archive->local_copy);
+#else
 	mime_type = get_mime_type_from_filename (archive->local_copy);
+#endif
 	if (! create_command_to_load_archive (archive, mime_type)) {
 		mime_type = get_mime_type_from_content (archive->local_copy);
 		if (! create_command_to_load_archive (archive, mime_type)) {

[vkareh]

@cranes-bill - nice, I'll give this a try