Bug 7889

Summary: /bin/cpio fails to write tapes properly
Product: [Retired] Red Hat Linux Reporter: danvi
Component: cpioAssignee: bero
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://danvi.vi
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-12-19 17:41:12 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 danvi 1999-12-19 11:23:22 UTC 
When backing up files on a DAT drive I go to the directory where the
files are located then give the command:

find . -depth -print | cpio -ovB > /dev/st0

The DAT tape (on an HP SureStore DAT8 drive) does write to the tape
and goes merrily on its way until the task is completed. With a false
sense of security, one puts the tape on read-only and stores it.

The shock comes when extacting the files by going to the directory
where they are to be written and issuing the command:

cpio -ivBdm < /dev/st0

Interspersed between each file message is the message:

	skipped 28 bytes of junk
	skipped 2746 bytes of junk

and similar messages. Some of the files are restored ok; some are
restored corrupted; and others are missing in their entirety.

I note that the 6.1 version of /bin/cpio is only about 48k while
other versions are over 292k. By writing DAT tapes with an earlier
version (or the SCO version) one gets a good, restorable tape.
Comment 1 Jeff Johnson 1999-12-19 17:41:59 UTC 
*** This bug has been marked as a duplicate of 6376 ***