Bugzilla Bug 87540

I have used Gnu tar to backup large filesystems to my DDS-4 tape drive for many
years.  After upgrading to tar-1.15.1, however, creating multi-volume archives
fails partway through the process:

delta-9 media # tar --multi-volume -cf /dev/st0 a* b* c* e* m* o* v*
Prepare volume #2 for `/dev/st0' and hit return:
Prepare volume #3 for `/dev/st0' and hit return:
Prepare volume #4 for `/dev/st0' and hit return:
Prepare volume #5 for `/dev/st0' and hit return:
Prepare volume #6 for `/dev/st0' and hit return:
tar:
mp3/AntiPop_Consortium/Antipop_Consortium_vs_Matthew_Shipp/07-antipop_consortium-stream_light-chr.mp3:
file name too long to be stored in a GNU multivolume header
tar: Error is not recoverable: exiting now
delta-9 media #

If you're saying to yourself "but that file name isn't very long", you're
right.  I am absolutely sure that this error message is incorrect.  Besides the
fact that I have backed up this filesystem using Gnu tar for many years without
ever seeing this error message, there is another reason why I am sure this
error message is incorrect:
During the exact same backup command, Gnu tar had absolutely no problem backing
up a file with this name:
c64/traunstaas_C64_dats/Commodore64 E-M (Corinthian 0.3)/Mystery Of The Nile,
The (MadeInSpain&SoftwareCreations&Firebird)(19xx)(triad).zip

I have tried running this backup twice so far, both failed with the same error
message, though on different files.  

I really have no idea what could be causing this (of course the incorrect error
message doesn't help either).  Both times the failure happened after either
getting home from work or getting up in the morning, so perhaps its related to
the time gap between when gnu tar asks for a volume and when I replace the tape
and hit return.  Also its possible that its related to the file changing while
that backup is running... normally I would receive "file changed as we read it"
warnings from Gnu tar when backing up this filesystem... not because I had
actually changed the file but because the atime on the file had changed because
of the previous night's slocate scan.  Anyway, that's a couple guesses that
I've come up with as to what could cause this problem.

I am going to downgrade to tar-1.13.92-r3 and re-start the backup.  It takes a
few hours to backup to each tape, so I should be reporting back the results in
around 24 hours.


Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Portage 2.0.51.19 (!/usr/portage/profiles/default-linux/x86/2004.0,
gcc-3.3.5,glibc-2.3.4.20041102-r1, 2.6.10-ac12 i686)
=================================================================
System uname: 2.6.10-ac12 i686 AMD Athlon(tm) MP 2200+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb  9 2005,
13:04:50)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r1, 2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-mp -O2 -fomit-frame-pointer -s -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config
/usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown
/usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /usr/X11R6/lib/X11/xkb
/usr/X11R6/lib/X11/xkb/compat /usr/X11R6/lib/X11/xkb/geometry
/usr/X11R6/lib/X11/xkb/keycodes /usr/X11R6/lib/X11/xkb/keymap
/usr/X11R6/lib/X11/xkb/rules /usr/X11R6/lib/X11/xkb/symbols
/usr/X11R6/lib/X11/xkb/symbols/macintosh /usr/X11R6/lib/X11/xkb/symbols/pc
/etc/env.d"
CXXFLAGS="-march=athlon-mp -O2 -fomit-frame-pointer -s -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/slug/usr/portage"
PORTDIR_OVERLAY="/usr/slug/usr/local/portage"
SYNC="rsync://jove.eng.yale.edu/gentoo-portage"
USE="x86 3dnow X acpi aim alsa apache2 avi berkdb bitmap-fonts cdr crypt curl
divx4linux dvd emboss encode fam flac font-server foomaticdb fortran gdbm gif
gphoto2 gpm gtk gtk2 icq imagemagick imlib ipv6 java joystick jpeg kde libg++
libwww lirc mad mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls nptl
offensive oggvorbis opengl oss pam pdflib perl png python qt quicktime readline
real samba sdl slang spell sse ssl svga tcpd tiff truetype truetype-fonts
type1-fonts usb v4l v4l2 videos xml2 xmms xosd xv zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS

Something I forgot to make clear:  The error occurs immediately after replacing
a tape and pressing enter, it doesn't happen in the middle of a tape.

In the above example, I inserted tape volume #6, pressed enter and tar
immediately errored out without attempting to write to the tape volume.

does this work:
tar -cf test.tar a* b* c* e* m* o* v*

Unfortunately I cannot test that... test.tar would be around 150 gigabytes, and
I only have around 50 gigabytes free on the disk.

However, I just completed testing with tar 1.13.92.... it worked perfectly:
delta-9 media # tar --multi-volume -cf /dev/st0 a* b* c* e* m* o* v*
Prepare volume #2 for `/dev/st0' and hit return:
Prepare volume #3 for `/dev/st0' and hit return:
Prepare volume #4 for `/dev/st0' and hit return:
Prepare volume #5 for `/dev/st0' and hit return:
tar:
mp3/Hip-Hop_Compilations/Babu_The_Dilated_Junkie-Duck_Season_Volume_2/18-krs_one-underground-apc.mp3:
file changed as we read it
Prepare volume #6 for `/dev/st0' and hit return:
Prepare volume #7 for `/dev/st0' and hit return:
Prepare volume #8 for `/dev/st0' and hit return:
Prepare volume #9 for `/dev/st0' and hit return:
delta-9 media #

I've checked /var/log/messages and dmesg, and have found no error messages from
the times that tar 1.15.1 failed.  My tape drive is on an adaptec card which
uses the aic7xxx driver... normally that driver produces alot of debug output
so if there was a hardware error I probably would know about it.

All of the other variables (kernel version, etc) were the same during my
testing... tar 1.15.1 failed both times I tried to use it, and tar 1.13.92
worked perfectly the first time I tried it.... so its looking more and more
like this error is a bug in tar 1.15.1.

I've brought this upstream:
http://lists.gnu.org/archive/html/bug-tar/2005-04/msg00012.html

thus far I've gotten this response:
http://lists.gnu.org/archive/html/bug-tar/2005-04/msg00015.html

I'll try out the patch tonight.

thanks :)

So, this problem is resolved upstream:
http://lists.gnu.org/archive/html/bug-tar/2005-04/msg00061.html

There is a patch here:
http://lists.gnu.org/archive/html/bug-tar/2005-04/msg00015.html

But with the patch tar outputs an alarming warning message about a filename being truncated, which in fact is not the case:
http://lists.gnu.org/archive/html/bug-tar/2005-04/msg00019.html

I'm content to use my patched version of tar until a new official release is made.  I guess whether to fix this problem in the Gentoo ebuild or wait for another official release is up to you guys.

is the only patch we need to fix 1.15.1 this one ?
http://lists.gnu.org/archive/html/bug-tar/2005-04/msg00015.html

we can ignore the spurious warning issue since that'll be resolved in the next release ... at least this way we'll have a better working version than the current ...

Yes, that's the only patch needed.

that patch is now in our 1.15.1 ebuild

thanks for all the work in getting this resolved ! :)