Xref: utzoo comp.unix.microport:1820 comp.unix.questions:9797 comp.unix.wizards:11798 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!convex!texsun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!philmds!hulsebos From: hulsebos@philmds.UUCP (Rob Hulsebos) Newsgroups: comp.unix.microport,comp.unix.questions,comp.unix.wizards Subject: Re: Corrupted backup floppies from cpio Message-ID: <838@philmds.UUCP> Date: 18 Oct 88 08:27:25 GMT References: <6794@chinet.chi.il.us> <4873@b-tech.ann-arbor.mi.us> Reply-To: hulsebos@philmds.UUCP (Rob Hulsebos) Organization: Philips I&E DTS Eindhoven Lines: 25 In article <6794@chinet.chi.il.us> johnk@chinet.chi.il.us (John Kennedy) writes: >When I went to restore the files, with a cpio -icdumv < /dev/rdsk/0s24, >the first few disks read okay, but then the "out of phase. get help" >message appeared. Apparently the disks were not written correctly. Yes, I've seen this bug too. Apparently, when 'cpio' writes to its output- device but gets an error, it just cancels writing the current file without giving an error, and continues with the next file. But because a header is already written to floppy, and the file written after the header does not match the length noted in the header, 'cpio' gets out-of-sync when it reads the disk back :-( Tar behaves better in this aspect. To my humble opinion, 'cpio' should at least give an error-message. As it is now, you're required to read back disks written with 'cpio' immediately after they have been made, unless you're 100% sure that the disks are OK. In article <4873@b-tech.ann-arbor.mi.us> zeeff@b-tech.UUCP (Jon Zeeff) writes: >You can use the fixcpio program or I believe that you can use afio. >Sources for both should be available from archive sites. The best solution would be to fix 'cpio'. ------------------------------------------------------------------------------ R.A. Hulsebos, Philips I&E Automation Modules ...!mcvax!philmds!hulsebos Building TQ-III-1 room 11 phone: +31-40-785723 Eindhoven, The Netherlands "f77 hello.c; a.out" works!