Bug 78310

Summary:	tar doesn't properly terminate a tape archive written to an IDE tape unit.
Product:	[Retired] Red Hat Linux	Reporter:	Charles Sullivan <cwsulliv>
Component:	kernel	Assignee:	Pete Zaitcev <zaitcev>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Levenson <benl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-30 15:40:13 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Charles Sullivan 2002-11-21 00:25:27 UTC

Description of Problem: The last file in a tape archive is improperly written by tar to an IDE tape drive under Red Hat 7.2. A verify, list-contents, or restore operation results in the error message "tar: Unexpected EOF in archive" when the last file is reached (or the last two or three files if they are small). This problem does not occur with Red hat 6.2.

Version-Release number of selected component (if applicable):
'tar --version' reports "tar (GNU tar) 1.13.25"
'rpm -q kernel' reports "kernel-2.4.18-17.7.x"

How Reproducible: Always.

My hardware configuration:
/dev/hda DVD ATAPI IDE drive
/dev/hdb (unused)
/dev/hdc CD-RW ATAPI IDE drive
/dev/hdd Seagate STT20000A 10/20 Gb Travan-5 ATAPI IDE Tape drive.
/dev/hde HDD (on Promise UDMA 66 card)

Steps to Reproduce:
1.
Clean install of Red Hat 7.2 Gnome workstation from official Red Hat CDs.
-- or --
The same Red Hat 7.2 fully upgraded via 'up2date'.

2. (Example):
tar -Wcvf /dev/st0 /bin/*
-- or --
tar -cvf /dev/st0 /bin/*
tar -tf /dev/st0 /bin/*

Actual Results:
"tar: Unexpected EOF in archive"
is displayed when the last file is being verified.

Expected Results:
Normal completion.

Additional Information:
With a clean install of Red Hat 6.2 Gnome workstation and the command:
tar -Wcvf /dev/ht0 /bin/*
the problem does not occur. And if the archived files are restored (to a different directory), they compare exactly with the originals.

A clean install of Red Hat 7.2 Gnome workstation replacing RH 6.2 on the same HDD as above exhibits the problem.

It's not clear to me why specifying ide-scsi for hdc also affects hdd, but removing the 'append="hdc=ide-scsi"' from the stanza in /etc/lilo.conf makes no difference. (Yes, I reran /sbin/lilo and rebooted.) Nor does adding "hdd=ide-tape" to the stanza make
any difference.

Whan any file in the tape archive (other than the one where tar stumbles) is restored, it compares exactly with the original.

Comment 1 Jeff Johnson 2002-11-21 18:03:36 UTC

This smells like a ide tape kernel driver problem, as tar has not
a clue about ide vs. any other type of tape device.

Comment 2 Charles Sullivan 2002-11-22 04:58:19 UTC

I'm not so sure about that.  First I must tell you that my initial report was mistaken in
saying that the EOF error was displayed when either 'tar -Wcvf ...' or 'tar -cvf ...' followed by 
'tar -tf ...' was run.  At least with the most recent kernel update, only 'tar -Wcvf ...' results
in that message.  (My report may be true with the clean install of RH 7.2, but I swapped
out hard drives for that test so can't easily recheck.  If you think it's important, I'll do it again.)

But now look.  I ran the following tests:
  cp  /bin/* .
  tar  -cvf  /dev/ht0  *
  dd  if=/dev/ht0  of=tartest1  bs=10240
  mv  tartest1  /tmp

  tar  -Wcvf  /dev/ht0  *
  dd  if=/dev/ht0  of=/tmp/tartest2  bs=10240

The file /tmp/tartest2 is shorter than /tmp/tartest1 !!
It looks to me like tar is truncating the archive when
the -W option is used.  

I tried repeating the same test but writing the archive to
a file on the HDD instead of the tape - this time there 
was no difference in size.

Comment 3 Bugzilla owner 2004-09-30 15:40:13 UTC

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/