LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   LinuxQuestions.org Member Success Stories (https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/)
-   -   invalid compressed data--format violated (https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/invalid-compressed-data-format-violated-782223/)

holland.d 01-14-2010 12:20 PM

invalid compressed data--format violated
 
I had this problem a year or so ago, and couldn't figure it out then.

I have a gzipped tar file <file>.tar.gz that I downloaded from a known good source. I have untared it on several machines without issue, but could not untar it today on a new machine. I tried gzip standalone first, rebooted, got a fresh copy from the original source all to no avail.

So I copied the file from <file>.tar.gz to <file>.tgz

then tar xvfz <file>.tgz worked flawlessly.

Just too weird, but it might help me next year when I search for this problem again :-)

ChrisAbela 01-14-2010 02:50 PM

Are you sure that it is a gzip file?

Try:

$ file <file_name>.tar.gz

and post the result

Also, which distro are you using? I have seen problems with archaic Tru64 machines when untaring Linux tarballs.

Note that:

$ tar xvf <compressed_tarball>

almost always works on a modern Linux install.

holland.d 01-14-2010 04:20 PM

Chris,

The distro is FC8 running in a VM on my intel laptop.

root@drm-test ~]# uname -a
Linux drm-test 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
[root@drm-test ~]#

The error messsage is

tar: Skipping to next header

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
[root@drm-test local]#

the result of 'file' is
[root@drm-test local]# file name.tar.gz
name.tar.gz: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
[root@drm-test local]#

For the record the other time I had this issue I was running on an hp laptop with SuSe 10 64bit and the archive was also sourced from a Win machine.

It may well be related to the arch, but it is a weird fix. I suppose I could dig into tar and see how they process the exstentions differently for a definitive answer. Oh the tar is :

root@drm-test local]# tar --version
tar (GNU tar) 1.17
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
[root@drm-test local]#

ChrisAbela 01-15-2010 09:44 AM

I suspect that they might have used another version of tar or or a tar-bug. You are using a quite old version of tar. After unzipping, what does file tell us:

$ gunzip <file_name.tar.gz>
$ file <file_name.tar>

holland.d 01-16-2010 12:49 PM

Chris,

gunzip generated the same response as tar for <file>.tar.gz file (I tried that first).
As such there is no <file>.tar to run 'file' against.

Technically the result is -
gzip: <file>.tar.gz: invalid compressed data--format violated
[root@drm-test tmp]#

Also I ran that same file as a tar.gz file on another 64 bit fc8 vm and it worked.

Same uname -a output on both systems (except for the system name) and same tar --version result.

Both machines were FC8 vm's running on vmware (different version of vmware) that had been configured from a common system setup script (with the tar.gz file bundled in). These are testing environments so aside from the original base machine install (yes many hundreds of packages) they are pretty standard package wise.

When I ran 'gunzip' then 'file' on this other machine the result was

<file>.tar: POSIX tar archive

I know it seems like I must be omitting some crucial piece of data to explain what I did wrong, but there isn't any more to it. I just renamed (don't remember if I copied or moved) the file and it worked.

What makes this so weird is that the same file (well a copy of it, I didn't mount the fs) worked in what was effectivly the same environment. One alternative is that the act of copying the file "fixed" the bad bits in the original file, but that path leads to madness so lets agree not to consider it.

It has to be a (pretty subtle) difference in the machines (oh by the way, other ".tar.gz" files untarred without issue on this same machine).

There is no magic! This is a problem with a real root cause that is some kind of bug (or pilot error :-) but it happend to me twice now and until I retire and have the time too look, renaming is a viable option. Having that option might save someone a flame war.

ChrisAbela 01-17-2010 02:27 PM

Flame wars are for kids, I never get involved in them :-), but we have to admit that running Fedora on vmware is not the most stable platform.

Do the <file_name.tar.gz> and <file_name.tgz> give the same md5sum result?

I made a quick google search and it appears that bugs did exist (and probably still do) in the tar application. Is this file a block device - like a partition? Is it a sparse file?

holland.d 01-26-2010 05:31 PM

Sorry to take so long to reply.
The "flame war" reference was really the miscommunication between the guy who was sending me the file (the first time this happened) and me. To me it seemed like he was repeatedly sending a bogus file and to him I looked like an idiot who could not untar a zipped file :-)

I kinda moved on from the problem, but I would bet a penny or two the md5sums are the same ('cause that is another entrance into the copying changed the bits maze, we can't go there.)

It is a regular file, and given that it is zipped I doubt it is sparse.

My best guess is that tar takes a different code path for the different extensions.


All times are GMT -5. The time now is 10:59 AM.