SVr4 cpio anomaly?
Andy Crump
andyc at bucky.intel.com
Fri Mar 1 21:18:30 AEST 1991
>>>>> On 27 Feb 91 21:59:22 GMT, davec at shared.uucp (Dave Close) said:
Dave> System: 386 with Intel SVr4v2. No tape drive.
Dave> Problem: Backup. A 2 GB tape is available on the net. I backup with the
Dave> command,
Dave> cd /; find . -print | cpio -o | rsh tapesys dd of=/dev/rmt1 obs=51200
Dave> It works reasonably well. I try to verify the backup with the command,
Dave> rsh tapesys dd if=/dev/rmt1 | cpio -itv
Dave> I quickly abort the verify because disk activity and the messages output
Dave> indicate that cpio is actually restoring the files, NOT just displaying
Dave> their names. I get messages about files being skipped since the disk version
Dave> is newer and messages about an inability to link files which are already
Dave> linked. This doesn't seem right! The man page for cpio clearly says that
Dave> "no files are created" when using the -t switch.
Dave> Is this a known bug or something I'm doing wrong?
I'm not sure. This is not a bug in the next version at least. I
tried it just as you described. It works for me, even if I touch some
of the files after backing them up. I did it as a mortal user rather
than root just to make sure and it work fine for me. You are correct
in that the -t should not restore any files! If it was a but in
SVR4.0.2 it doesn't seem to be a bug in the next version. If you have
more info, I would be happy to try it out.
Dave> BTW, the man page for rsh on my system is linked to sh, that is, it is the
Dave> man page for a restricted shell. But the rsh command is the expected remote
Dave> shell. Seems like another minor slip-up.
Yup. But this is the Online Manual package that is not normally a
part of the USL SVR4 distribution. This was from the now defunct IMSO
group within Intel. I don't believe there is any support for that
package. You can check by calling 1-800-INTEL4U.
--
-- Andy Crump
...!tektronix!reed!littlei!andyc | andyc at littlei.intel.com
...!uunet!littlei!andyc | andyc at littlei.uu.net
Disclaimer: Any opinions expressed here are my own and
not representive of Intel Corportation.
More information about the Comp.unix.sysv386
mailing list