[Bug-tar] tar 1.15.1 fails creating multivol tape archive, outputs incorrect error

[Jim Faulkner]

First reported here:
http://bugs.gentoo.org/show_bug.cgi?id=87540

I have used Gnu tar for several years to back up various filesystems to a
DDS-4 tape drive.  However, tar version 1.15.1 fails to complete archiving
one of my large filesystems, and outputs an obviously incorrect error
message when failing.

Partway through a backup using tar 1.15.1, tar will error out.  Please
note that this *only* happens at the very beginning of a tape, immediately
after inserting the next tape volume and pressing enter.

Here is the output of a failed backup using tar 1.15.1:
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 #

Having backed up this filesystem using previous versions of Gnu tar, I
know that the file name is most certainly not too long for a multivolume
tar archive.  However, I also know that this error message is incorrect
even for version 1.15.1, because earlier in the above backup (probably
around tape volume #1 or #2), tar 1.15.1 had no complaints while backing
up this file:
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 and on different tape volumes.
As I said before, it errors out immediately after pressing "enter" to
indicate that the next tape volume is ready.

To be sure that this was a problem with tar 1.15.1, I downgraded to tar
1.13.92 and did the backup... it worked fine:
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 found no errors, so this
does not appear to be a hardware or operating system problem.

Perhaps it is related to my overnight cronjob which chown's files
under the mp3/ directory (and thus causes the "file changed as we read it"
messages in working versions of tar), but I have not looked at the source
code so that is just a guess.

This bug is a showstopper for me, so I'm willing to wear out a few tapes
testing possible solutions to this problem.  Please CC my e-mail address
in any replies, as I am not subscribed to this mailing list.

thanks,
Jim Faulkner