LinuxQuestions.org Member Success StoriesJust spent four hours configuring your favorite program? Just figured out a Linux problem that has been stumping you for months?
Post your Linux Success Stories here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 :-)
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]#
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 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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.