Hello list,
We just hit an apparent bug in GNU tar that causes it to barf on a
multi-volume archive which happens to contain a "long file name" on the span
between two tapes.
It runs the backup fine, but on a -d (--diff) (and, presumably, -x
(--extract)), when it reaches that file, the whole thing blows up with this
error:
tar: `file_name' is not continued on this volume
Past that point, it reads through every tape, spitting out that message at
the end of each one. Eventually, it falls off the end of the tapeset and
prompts for the next (non-existent) tape.
It appears that the archive is actually mostly intact. If I load the
first tape after the problem, I can in fact list the contents or extract
files. It appears that just the file header is hosed up, or perhaps that
single file. I am not willing to trust that, though.
Apparently, this is a known bug, or at least, to some. It looks like it
is documented in the source, in src/buffer.c, as follows:
> /* FIXME: Michael P Urban writes: [a long name file] is being written
> when a new volume rolls around [...] Looks like the wrong value is
> being preserved in real_s_name, though. */
Isn't that special.
That comment appears both in the 1.13.17 and the latest 1.13.25 beta
release, so it has been there for awhile (at least since 2000).
In general, I find current information about GNU tar (or GNU cpio) to be
very sparse. In fact, I would go so far as to suggest that they appear to
be unmaintained.
I am going to email the listed maintainer for GNU tar, but I wanted to
post this information here as well, to try and get the word out to at least
a few people, and on the off-chance anyone has any ideas (aside from using
shorter file names).
--
Ben Scott | Net Technologies, Inc. | 978-462-8795
Network Engineer | Salisbury, MA, USA | 866-NTI-LINUX (684-5468)
[EMAIL PROTECTED] | http://www.ntilinux.com | Fax: 978-499-7839
*****************************************************************
To unsubscribe from this list, send mail to [EMAIL PROTECTED]
with the text 'unsubscribe gnhlug' in the message body.
*****************************************************************