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 :-)
Are you sure that it is a gzip file?
$ 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.
$ tar xvf <compressed_tarball>
almost always works on a modern Linux install.
The distro is FC8 running in a VM on my intel laptop.
root@drm-test ~]# uname -a
Linux drm-test 22.214.171.124-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
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
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)
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.
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>
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
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.
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?
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 12:43 AM.|