jackv@turnkey.gryphon.COM (Jack F. Vogel) (11/09/89)
In article <1178@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >I have been shipping many cpio files from a SYSV system to my >AIX PS/2 system. For most of these files, cpio has worked quite nicely. >On one, it aborts with: > Out of phase -- get help. >What does this mean, and what can I do about it? Kevin, cpio has fixed length records as headers for the elements of its archive; without looking at the source, I believe the out of phase message means it got an error in scanning the header records. Since I recently fixed a problem with cpio that caused it to mangle headers when dealing with special device files I know that this problem is in the 1.1 version. (That may not be the cause of your error, however.) I would recommend anyone running 1.1 not use cpio to backup your local filesystem, it will create an archive without errors but will bomb trying to restore it. Now, as for what you can do. One question is, do you get the out-of-phase error immediately or only after reading some portion of the archive?? If the former, I suggest you may have a bad archive and might well not be able to recover. If the latter, I recommend you lay your hands on afio, which can recover from errors in an archive and continue. As a matter of fact, afio might even recover some portion of the archive in either case. Also, are you using the B flag in your read command, if not you might try and include it. You can obtain afio from any unix.sources archive, and, yes, I have built it without too many problems under AIX/PS2. Good luck! Disclaimer: This is not an official posting, my opinions only. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
peter@sersun1.essex.ac.uk (Allott P) (11/09/89)
In article <1178@msa3b.UUCP> >For most of these files, cpio has worked quite nicely. >On one, it aborts with: > Out of phase -- get help. >What does this mean, All cpio "tape" blocks start with a "Magic number", I think this is 0707 but don't take my word for that. If the "Magic number" is not there on read back you get the error message. This can be caused by one (or more) of the following. (1) The "tape" was written with the "c" option and read back without it. (2) The "tape" was written without the "c" option and read back with it. (3) The tape was written on a machine with the bytes stored internally in a different order to that on the machine on which is is being read. AND the "c" option was not used. (4) The "tape" has suffered a hardware read (or write) error. (5) The tape was written in "c" mode and contains file(s) with a negative uid (or gid) (ie. "Nobody") > and what can I do about it? Find the cause of the problem. if (1) or (2) - Use the correct option. if (3) - Read the tape on a machine with the correct byte order. I think the later versions of cpio sort this problem out for you - reading tapes writen on machines with diffent byte orders even if in non-"c" mode. if (4) - Try again. We have source and spent some time, trying to get a version which would recover, I would need some proof of licence status before I send our mods to the source. (These are based on quite an old version of cpio) if (5) - Panic. Well not quite. I cannot see a way of recoving this sort of dump. (It bit us some months ago). I have a version which will write readable tapes in "c" mode even if -ve uids exist on your machine.
todd@janus.UUCP (Todd Booth) (11/10/89)
In article <6393@turnkey.gryphon.COM>, jackv@turnkey.gryphon.COM (Jack F. Vogel) writes: > I would recommend anyone > running 1.1 not use cpio to backup your local filesystem, it will create > an archive without errors but will bomb trying to restore it. And I would recommend not using cpio to xfer files from a remote Unix system TO AIX since I to have received the out-of-phase error transfering from a SYS V based system to AIX. Therefore between our two suggestions don't use cpio. My solution was to use tar. --todd booth
jon@jonlab.UUCP (Jon H. LaBadie) (11/11/89)
In article <6393@turnkey.gryphon.COM>, jackv@turnkey.gryphon.COM (Jack F. Vogel) writes: > In article <1178@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: > >I have been shipping many cpio files from a SYSV system to my > >AIX PS/2 system. For most of these files, cpio has worked quite nicely. > >On one, it aborts with: > > Out of phase -- get help. > >What does this mean, and what can I do about it? If the files you have on the diskette are textual in nature, I have a final solution. Note, Jack's mention of afio is one I too would make. As long as you can read the diskette, it is not a medium (ie. munged magnetic material) and you can get all of your files onto your hard disk. Use either cat /dev/fXXXX or dd -i /dev/fXXXX to create an image of your diskette on the hard disk. Once you have that image, you can try to edit it. HOWEVER, most UNIX editors have a size limitation - generally about 256K. It may be necessary for you to do some "split"ing (check the manual) to get pieces small enough to edit. Again, assuming the files are text files, there will be a large block of text that is an image of the original file. It will be "surrounded" by header information that will either be binary or textual depending on the flags used to create the archive. Again, assuming text files are archived, you can use the editor to write those portions of the diskette image that constitute the file. for example, you may enter the vi command ":29,204w file_one" command. This would assume that you had deduced that the file you wanted was in the floppy image between lines 29 and 204. I suspect by now you are getting the idea of how I would suggest you proceed. If you have any questions, contatct me via email. -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon
guy@auspex.auspex.com (Guy Harris) (11/14/89)
>All cpio "tape" blocks start with a "Magic number", I think this is 0707 >but don't take my word for that. From the SunOS 4.x "/etc/magic", derived from the S5R3.1 one: 0 short 070707 cpio archive 0 short 0143561 byte-swapped cpio archive 0 string 070707 ASCII cpio archive I.e. non-"-c" archives start with a 2-byte quantity that has the value octal 70707 if the archive was written on a machine with the same byte order and octal 143561 if it was written on a machine with the opposite byte order (we're talking 2-byte quantities here, there are only two byte orders for them). "-c" archives start with 6 bytes containing the ASCII characters "0", "7", "0", "7", "0", and "7", in order. >if (3) - Read the tape on a machine with the correct byte order. > I think the later versions of cpio sort this problem out > for you - reading tapes writen on machines with > diffent byte orders even if in non-"c" mode. The only version I know of that does so is the SunOS one in releases 3.2 and later, and that's only because I stuck in the code to make it do so. Vanilla versions from AT&T don't do so. (It ain't that hard; if the magic number isn't 070707, check whether it's 0143561 and, if so, set a flag that causes "cpio" to byte-swap only the "cpio" headers - *not* the file names *nor* the file data.)