GNU tar problem

5 views
Skip to first unread message

Everett M. Greene

unread,
Feb 24, 2008, 12:53:14 PM2/24/08
to
I've been using a 1998 version of Gnu tar for years and
it has worked fine. Recently, it has started balking at
working correctly. It's suffering from bit rot with age?

The specific problem is that (almost) regardless of the
file it's told to archive, it returns an error message
of "<file name>: Unknown file type; file ignored."
What's really mystifying is how a file can be of the
wrong type for tar since tar shouldn't be concerned
with a file "type". [I strongly suspect the error
message is erroneous.]

Has anyone else encountered this problem?

Hans-Bernhard Bröker

unread,
Feb 24, 2008, 2:18:37 PM2/24/08
to
Everett M. Greene wrote:

> The specific problem is that (almost) regardless of the
> file it's told to archive, it returns an error message
> of "<file name>: Unknown file type; file ignored."

And this relates to embedded systems how?

That set aside, even if you think the failure happens regardless of the
file it's told to archive, that doesn't mean we can actually read your
mind over the internet to see what the actual commands passed to that
ancient version of 'tar' might have been.

> What's really mystifying is how a file can be of the
> wrong type for tar since tar shouldn't be concerned
> with a file "type".

The files _in_ the archive are not likely to affected. The archive
itself, however, must be a tar file for this to work. And then there's
the possibility that you may have been requesting a special feature of
your tar version to recognize text files and treat them differently.

And 'bit rot' is quite a lot less likely the reason than a superficially
unrelated change to your system having changed what actually gets
executed when you call "tar" on the command line.

Everett M. Greene

unread,
Feb 25, 2008, 10:46:18 AM2/25/08
to
Hans-Bernhard_Br=F6ker?= <HBBr...@t-online.de> writes:
> Everett M. Greene wrote:
>
> > The specific problem is that (almost) regardless of the
> > file it's told to archive, it returns an error message
> > of "<file name>: Unknown file type; file ignored."
>
> And this relates to embedded systems how?

Directly, not at all. Indirectly, quite widely.

> That set aside, even if you think the failure happens regardless of the
> file it's told to archive, that doesn't mean we can actually read your
> mind over the internet to see what the actual commands passed to that
> ancient version of 'tar' might have been.
>
> > What's really mystifying is how a file can be of the
> > wrong type for tar since tar shouldn't be concerned
> > with a file "type".
>
> The files _in_ the archive are not likely to affected. The archive
> itself, however, must be a tar file for this to work. And then there's
> the possibility that you may have been requesting a special feature of
> your tar version to recognize text files and treat them differently.

This is happening when creating a tar archive so there
is no previous content with which to be concerned. I
have numerous canned processes that I've used for years
and now they don't work at all.

> And 'bit rot' is quite a lot less likely the reason than a superficially
> unrelated change to your system having changed what actually gets
> executed when you call "tar" on the command line.

I've found a later version of tar that I can try except
that the developer of the update decided to package the
components as a tar file. I can't untar the package to
get the updated tar!

Hans-Bernhard Bröker

unread,
Feb 25, 2008, 5:52:24 PM2/25/08
to
Everett M. Greene wrote:
> Hans-Bernhard_Br=F6ker?= <HBBr...@t-online.de> writes:

>> That set aside, even if you think the failure happens regardless of the
>> file it's told to archive, that doesn't mean we can actually read your
>> mind over the internet to see what the actual commands passed to that
>> ancient version of 'tar' might have been.

Why did you not this? Do you seriously expect people to be able to
help without seeing any actual command line input or error message
output from that mysterious, anonymous "tar" you're referring to?

> I have numerous canned processes that I've used for years and now
> they don't work at all.

And you consider them so sacred that you can't show any of them?

>> And 'bit rot' is quite a lot less likely the reason than a superficially
>> unrelated change to your system having changed what actually gets
>> executed when you call "tar" on the command line.

> I've found a later version of tar that I can try except
> that the developer of the update decided to package the
> components as a tar file.

You missed my point. You say that "now" it no longer works --- so
something must have changed between "then" and "now". Since you left us
with nothing to work on, you'll have to find out yourself what that
something is. It may help to start with "when?", then proceed to "what
did I do then?"

It can hardly be bit rot of the software itself, so the change is
probably in your system enviromnent. E.g. you could unknowingly have
installed *another* program also called "tar", which now gets called
under that name, but does a totally different job, or expect options in
a different format. Or you could have changed the system-wide presets
of your tar program.

ArarghMai...@not.at.arargh.com

unread,
Feb 25, 2008, 6:17:24 PM2/25/08
to

Edit it as a binary file, and pick off the pieces.
--
ArarghMail802 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

CBFalconer

unread,
Feb 25, 2008, 3:50:05 PM2/25/08
to
"Everett M. Greene" wrote:
>
... snip ...

>
> I've found a later version of tar that I can try except that the
> developer of the update decided to package the components as a
> tar file. I can't untar the package to get the updated tar!

A tar file is an extremely simple thing. The content files
themselves are simply copies, preceded by an indexing prefix. The
prefix describes such things about the file as dates, length, etc.
There may be an overall prefix which summarizes all the prefixes.
So extraction, after deciding which file to extract, is simply
copying a portion of the tar file.

Some tar files are also compressed, and these are normally marked
as .tgz files, or as .tar.gz files. Uncompressing the .tgz with
gzip will yield a tar file, and the above applies.

.zip files are generally a better (and newer) mechanism. But that
does not address your problem.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

David Brown

unread,
Feb 26, 2008, 8:24:49 AM2/26/08
to
CBFalconer wrote:
> "Everett M. Greene" wrote:
> ... snip ...
>> I've found a later version of tar that I can try except that the
>> developer of the update decided to package the components as a
>> tar file. I can't untar the package to get the updated tar!
>
> A tar file is an extremely simple thing. The content files
> themselves are simply copies, preceded by an indexing prefix. The
> prefix describes such things about the file as dates, length, etc.
> There may be an overall prefix which summarizes all the prefixes.
> So extraction, after deciding which file to extract, is simply
> copying a portion of the tar file.
>
> Some tar files are also compressed, and these are normally marked
> as .tgz files, or as .tar.gz files. Uncompressing the .tgz with
> gzip will yield a tar file, and the above applies.
>
> .zip files are generally a better (and newer) mechanism. But that
> does not address your problem.
>

zip files are *not* "generally a better mechanism". Zip files and tgz
(or tar.bz2) files have different strengths and weaknesses, and are used
in different places. One difference is that zip files are more common
in the DOS+Windows world, while tar and tar.gz are more common in the
*nix world. On a technical level, zip files consist of a bunch of files
that are compressed, then bundled together, while tgz files consist of a
bunch of files that are bundled together, then the whole bundle is
compressed. This makes zip files better if you want to work with
individual files in the archive (adding new files, extracting a few
files), and means less memory will be needed for compressing or
extracting files. tgz files will give better compression, especially
for many similar files, and are better suited to streaming and
pipelining usage (there is no "tar-gzip" program - the output of "tar"
is piped directly into "gzip"). So neither format is "better", even
though they overlap somewhat is usage.

CBFalconer

unread,
Feb 26, 2008, 3:52:31 PM2/26/08
to
David Brown wrote:
> CBFalconer wrote:
>
... snip ...

>
>> .zip files are generally a better (and newer) mechanism. But
>> that does not address your problem.
>
> zip files are *not* "generally a better mechanism". Zip files and
> tgz (or tar.bz2) files have different strengths and weaknesses,
> and are used in different places. One difference is that zip
> files are more common in the DOS+Windows world, while tar and
> tar.gz are more common in the *nix world. On a technical level,
> zip files consist of a bunch of files that are compressed, then
> bundled together, while tgz files consist of a bunch of files
> that are bundled together, then the whole bundle is compressed.
> This makes zip files better if you want to work with individual
> files in the archive (adding new files, extracting a few files),
> and means less memory will be needed for compressing or extracting
> files. tgz files will give better compression, especially for
> pipelining usage (there is no "tar-gzip" program - the output of
> "tar" is piped directly into "gzip"). So neither format is
> "better", even though they overlap somewhat is usage.

I have no disagreement with your facts, but I do feel your
evaluation is faulty, especially as long as you are using gzip.
bzip2 cam compress much better, but seems to upset those unfamiliar
with it. When using gzip with tar, as compared to just zip, I
think there is no replacement for the ability to extract individual
files. In addition, zip gives the ability to add or replace files
as required (although replacement hides the major complications).

Availability of utilities for packaging is about equal today.

At any rate this argument is much like arguing over code format.
:-)

David Brown

unread,
Feb 27, 2008, 3:30:12 AM2/27/08
to

I agree entirely about bzip2. But the ability to remove or add single
files to a zip file is almost irrelevant in practice (unless my usage is
widely abnormal) - virtually all zip files I make are packed and
unpacked in one action. And if I have a tgz (or tar.bz2) file from
which I just need a single file, any decent compressed file gui (such as
7zip on windows) will handle that fine.

Mostly the decision boils down to zip being natural on windows, and tgz
(and friends) being the natural choice on *nix.

My point is merely that you can't claim one format is so much better
than the other, when they can both do the same job, but with different
strengths and weaknesses.

> Availability of utilities for packaging is about equal today.
>
> At any rate this argument is much like arguing over code format.
> :-)
>

Yes, that's certainly true. Just like code formatting, there are many
ways to do compression - you do it in your way, and I do it the right way!

mvh.,

David

Albert van der Horst

unread,
Feb 27, 2008, 10:00:18 AM2/27/08
to
In article <20080224.7...@mojaveg.lsan.mdsg-pacwest.com>,

This is not true.
tar is very much aware of what type of file it handles and
treats normal files, directory files, symbolic links,
network mounts, char special devices etc. all differently.
So if it cannot find out whether or not a certain file
is a directory, it has every right to complain.

The first thing you should do is type
file <file name>
for offending files, and see what happens.
Chances are that ``file'' comes with the same message and
your trouble is not with tar.

>
>Has anyone else encountered this problem?

Some ways I can imagine to have this is creating an invalid
device, severe file system corruption or a botched network.

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

David T. Ashley

unread,
Feb 29, 2008, 1:31:10 AM2/29/08
to
"Everett M. Greene" <moj...@mojaveg.lsan.mdsg-pacwest.com> wrote in message
news:20080224.7...@mojaveg.lsan.mdsg-pacwest.com...

What OS?

Why haven't you upgraded your system?

Why are you posting on this newsgroup? (Why not alt.os.linux or something
OS-specific?)

Dave.

Everett M. Greene

unread,
Mar 1, 2008, 1:26:56 PM3/1/08
to
From: "David T. Ashley" <d...@e3ft.com>
> "Everett M. Greene" wrote

> > I've been using a 1998 version of Gnu tar for years and
> > it has worked fine. Recently, it has started balking at
> > working correctly. It's suffering from bit rot with age?
> >
> > The specific problem is that (almost) regardless of the
> > file it's told to archive, it returns an error message
> > of "<file name>: Unknown file type; file ignored."
> > What's really mystifying is how a file can be of the
> > wrong type for tar since tar shouldn't be concerned
> > with a file "type". [I strongly suspect the error
> > message is erroneous.]
> >
> > Has anyone else encountered this problem?
>
> What OS?
>
> Why haven't you upgraded your system?

Why? If it ain't broke,...

> Why are you posting on this newsgroup?

Which one?

> (Why not alt.os.linux or something OS-specific?)

Because tar is available on nearly every machine and OS.

Reply all
Reply to author
Forward
0 new messages