87540 2005-04-01 03:54 0000 app-arch/tar-1.15.1 fails creating multivolume archives, outputs incorrect error message 2005-04-26 20:35:21 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified All Linux RESOLVED FIXED P2 major --- 1 dogshu@sdf.lonestar.org base-system@gentoo.org dogshu@sdf.lonestar.org 2005-04-01 03:54:30 0000 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 dogshu@sdf.lonestar.org 2005-04-01 05:22:08 0000 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. vapier@gentoo.org 2005-04-01 16:49:20 0000 does this work: tar -cf test.tar a* b* c* e* m* o* v* dogshu@sdf.lonestar.org 2005-04-02 07:10:11 0000 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. dogshu@sdf.lonestar.org 2005-04-06 10:29:53 0000 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. vapier@gentoo.org 2005-04-06 16:33:30 0000 thanks :) dogshu@sdf.lonestar.org 2005-04-20 07:44:33 0000 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. vapier@gentoo.org 2005-04-20 19:01:53 0000 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 ... dogshu@sdf.lonestar.org 2005-04-21 08:25:21 0000 Yes, that's the only patch needed. vapier@gentoo.org 2005-04-26 20:35:21 0000 that patch is now in our 1.15.1 ebuild thanks for all the work in getting this resolved ! :)