foh@pkinbg.UUCP (Fohringer Bernhard) (06/26/90)
Here's my request ... has anyone in the field heard about a CPIO problem under SR10. It seems, that the cpio isn't able to restore symbolic links or binary data written by "applications" like MENTOR (REC format). If so, is there a patch available ??? Oh I forgot ... we don't want, like, expect or will use WBAK !!!!!! ==== ==== ====== ==== ============================================================================== Bernd Fohringer Phone: 0049 911 526-3735 Philips Kommunikations Industrie Fax: 0049 911 526-2063 Nuerberg, West Germany Mail: foh@pkinbg.uucp ============================================================================== ============================================================================== Bernd Fohringer Phone: 0049 911 526-3735 Philips Kommunikations Industrie Fax: 0049 911 526-2063 Nuerberg, West Germany Mail: foh@pkinbg.philips.uucp ==============================================================================
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (07/06/90)
You've got yourself a real problem ... CPIO, like all other *real* Unix programs, only understands one file type -- UNSTRUCT. There is no method for a standard Unix program to save and/or restore a file's object type (REC, UASC, OBJ, COFF, you name it). Only Apollo-specific programs such as WBAK/RBAK, or Apollo modified programs such as the "tar -A" option can handle non-Unix file types. If Mentor's application programs are creating non-Unix files, don't expect Unix applications (like CPIO, standard TAR, etc) to handle them. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
scott@labtam.oz (Scott Colwell) (07/09/90)
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: >You've got yourself a real problem ... Like David said.. There however are two seperate problems (at least :-) in using cpio on Mentor files, the first is that cpio does not seem to understand Apollo file types and the second is that Mentor uses symbolic links strangely to handle file versions. Why doesn't the manual entry for cpio say that it can't handle other than unstruct files ? It either should handle all files or be documented to not handle them (and preferably warn you too.) Mentor creates files as shown below: $ ls -S sheet1.pic -> $23 sheet1.pic_$22 sheet1.pic_$23 where 'sheet1.pic_$23' is the current version and 'sheet1.pic_$22' is the previous version. The link 'sheet1.pic' is used to figure out which is the current version. Note that the symbolic link actually points to '$23' not 'sheet1.pic_$23'. Cpio when it tries to archive 'sheet1.pic', it can't get any information on the file (maybe it tries to stat the file?), and prints an error message. I would prefer to use cpio rather than wbak/rbak for a number of reasons but have given up. At least wbak and rbak can use stdin and stdout now rather than being fixed to a device so that you can backup over the network to a larger QIC tape (QIC-150) or to an exabyte on one of our other machines. (Looking forward to the day when I can have Mentor on real unix :-) -- Scott Colwell Labtam Information Systems P/L net: scott@labtam.oz.au Melbourne, Australia phone: +61-3-587-1444
chen@digital.sps.mot.com (Jinfu Chen) (07/09/90)
In article <4962@labtam.oz> scott@labtam.oz (Scott Colwell) writes: > > I would prefer to use cpio rather than wbak/rbak for a number of reasons > but have given up. At least wbak and rbak can use stdin and stdout now > rather than being fixed to a device so that you can backup over the network > to a larger QIC tape (QIC-150) or to an exabyte on one of our other machines. > > (Looking forward to the day when I can have Mentor on real unix :-) If you meant SysV.3 is real Unix with which cpio uncapable handling symbolic link, then forget about the real Unix :-) At least tar (available in both Sys5.3 and Bsd4.3) lets you choose to follow a symbolic link or not. -- Jinfu Chen (602)898-5338 | Motorola, Inc. SPS Mesa, AZ | ...uunet!motsps!digital!chen | chen@digital.sps.mot.com |