GBOPOLY1@NUSVM.BITNET (fclim) (06/02/88)
hi,
does any domain/ix guru out there know why tar doesn't work
on my dn3000 with sr9.7 ? i have used
tar -tvf /dev/rct8
and the message is either
tar: cannot open /dev/rct8
or
tar: blocksize = 0
the tape was originally tar on a sun machine.
i also tried using dd:
dd if=/dev/rct8 if=x
and the message is
0+0 blocks in
0+0 blocks out
the size of x is 0.
this problem is not only on cartridge tape drives. i am also
having problems with mag-tapes. the message is
tar: cannot open /dev/rmt8.
these tar problems seem very strange as i have used tar successfully
before. when i first got an account on our apollo dn300 with sr9.2 (we
have only upgraded to dn3000 sr9.7), i've managed to tar 3 tapes without
any problems. later, i couldn't do anything with tar. the vendor told us
the problem was in sr9.2 and that apollo computers will fix it with sr9.7.
but it looks like they have not fixed it yet.
why did tar work with the first 3 tapes? does domain/ix tar
look at some environment variable (like SYSTYPE) before setting its
local parameters (as well as those of /dev/r?t*) and then extracting
the files? i think the problem lies in the environment.
otherwise, why would tar work so well with 3 tapes and then silently
went on strike? most probably, my lab manager has set the environ
for the 3 tapes and then unset it after that.
please help as i received my tapes from abroad in unix tar format.
any help is very much appreciated. many thanks in advance.
fclim
system programmer
computer centre
singapore polytechnic
dover road
s'pore.lwk@CAEN.ENGIN.UMICH.EDU (Lewis W Kellum) (06/02/88)
We've had similar problems. I created a new /dev/rmt8 with the
edmtdesc command, which worked fine. Any one know what's happening
to the /dev/r?t* ?
- Woody Kellumkrowitz@RICHTER.MIT.EDU (David Krowitz) (06/03/88)
Apollos can read Sun cartridge tapes IF (and only if) they are written in the correct density. Some of the Suns have two different device files for the cartridge tape (/dev/rst0 and /dev/rst8, if I remember correctly). The device with the lower number write a low density (QIC-11) tape and the one with the higher number writes a high density (QIC-24) tape which the Apollos can read. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
GBOPOLY1@NUSVM.BITNET (fclim) (06/06/88)
hi,
thanks to everyone who replied to my question about tar.
does the blocking factor == 1 inherent in apollo cartridge drive?
or will it increase with sr10? i am not too sure about the blocking
factor when the tape was made. i just think that it's a drag to
restrict all tapes to bf to 1. people who are willing to make tapes
for me do not wish to do at such low bf.
another thing: those who had replied did not consider my concern
about mag-tapes. long ago, i managed to tar 3 mag-tapes successfully.
several months after this, i couldn't tar, even with the original 3
mag-tapes. i keep getting "can't open /dev/rmt8" messages. this was on
dn300 with sr9.2; i have not tried out dn3000 with sr9.7. the mag-tape
drive couldn't have conk out in the meantime as we can still use
/com/[rw]bak. i think /[sys5 | bsd4.2]/bin/tar was the one that got
conked.
the 3 "good" mag-tapes are one that was made at waterloo, canada;
one from rms (fsf/gnu-emacs) and one from unix-tex (mackay@uwash).
these 3, i've managed to tar the first time round. later, i received
one (mag-tape) from nelson beebe (his utah's tex-dvi drivers family) which
couldn't be read with tar. this was the beginning of the end of the tar
on my apollo system; everytime i used tar after this, i got the above-
mentioned message. (note that utah-science.arpa is a top-20 machine;
although i believe tar is tar whether it's on top-20, sun or apollo).
i passed this utah tape over to a friend who had no problem on a sun
3/60. what's going on here?
i hope that the problem will get fixed at sr10.
--fclim.rees@DELRIO.CC.UMICH.EDU (Jim Rees) (06/13/88)
1) if the block size on the cartridge is > 512 bytes, throw away
the cartridge, APollo h/w is unable to read cartridges with
block size bigger than 512 (<help>media).
No, I wouldn't throw it out. It's true that a bug in the driver makes
it impossible to read more than 512 bytes at a time. But cartridge
tape isn't like magtape. If you read 20 records of 512 each, it's the
same (as far as the bits are concerned) as reading a single record of
10240. Apparently the tape records are fixed length, and the controller
fixes it up to look like a magtape. So you can read those tapes just
fine, as long as you use a block size of 512.
2) Usually helps:
/com/rbak -dev ct -reten
Or -rewind instead of -reten, if you're in a hurry. I only retension
if I'm writing. I think it even says to do this on the tar man page.
By the way, tar works great. It's the driver that's broken.
-------