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.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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 18.104.22.168-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.
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.
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.