murach@mips2.cr.bull.com (Lynne Murach) (09/11/90)
Hi folks! I am desperately trying to retrieve files from a streamer tape, but I am having many difficulties. The format of the tape is unknown. The command cpio -idcv < /dev/rmt/ctape0 causes one file to be extracted from the tape. When the "file" command is run on this extracted file, the type returned is cpio archive. I then run the command cpio -idcv < extracted_file, and a number of files are extracted. The problem is that before all of the files are extracted I get the following error: cpio: ERROR Out of sync. bad magic number/header. I am running on a MIPS M2000 under RISC/os 4.5. Does anyone out there know why this is happening and how I can fix it? The tape comes from over seas and if it all possible I would like to use the tape that I have. Please respond by e-mail because I don't always have time to read news. Thanks, Lynne Murach Bull Worldwide Information Systems Billerica, Massachusetts E-mail: murach@mips2.cr.bull.com
jimr@hp-lsd.COS.HP.COM (Jim Rogers) (09/13/90)
You should check to see if your version of cpio has the "R" option. On our system this option automatically resynchronizes cpio when it goes "Out of phase". To quote from our manual (HP-UX): "The diagnostic message 'Out of phase' indicates that cpio could not successfully read its particular 'magic number' in the header. Without the R option specified, cpio will fail and return exit code 2. With the R option, cpio will try resyncing automatically. (Resyncing means that cpio tries to find the next good header in the archive and continues processing from there.) If cpio tries to resynchronize from being 'Out of phase', it will return exit code 1. If resynchronization fails, try changing header mode (c option) or byte swapping the header (P or s options)." Jim Rogers Hewlett Packard Company
guy@auspex.auspex.com (Guy Harris) (09/29/90)
>If resynchronization fails, try changing header mode (c option) I think S5R3's "cpio" may do that automatically; HP's more recent HP-UX releases are S5R3-based, right? >or byte swapping the header (P or s options)." S5R3's "cpio" doesn't do that automatically, but Sun's does; everybody's *should* - especially given that the "s" option to the System V "cpio" byte-swaps *data*, not *headers*, and *cannot* be used to read a byte-swapped tape, even if you stick a "dd conv=swab" in the way! You needs some combination of things that ends up swapping bytes *only* in the headers and that leaves data *and* pathnames alone. I assume the "P" option in HP-UX's "cpio" does some form of byte-swapping that *does* let you read tapes not written with the "c" option, and written on a machine with the opposite byte-order-within-16-bit-quantities.