At 12:48 AM 12/5/1999 +0100, Wolfgang Weisselberg wrote:
>
>Trying to kill the keyboard, Michael Gersten ([EMAIL PROTECTED])
>produced 0,4K in 9 lines:
>
>> After doing a dump (by tar) to /dev/nrft0, and (several hours later,
>> in the morning) doing an mt rewind, (and hearing the 7 passes at
>> the start of the tape), the tape appears empty; 'mt seod; mt tell'
>> reports block zero, 'less -f /dev/tape' reports empty.
>> (yes, /dev/tape is symlink'd correctly).
>
>You might try ftmt instead of mt, ftmt is optimized for floppy
>tapes. Also, IIRC floppy tapes count *from the beginning of
>a file*, not from the beginning of the tape. Try ftmt status
>to see in which file you are.
>
>You'll also want vtblc, to read and modify the index at the
>beginning of the tape.
>
>> Version 3.04d, redhat 6.0.
>
>Uh, here in Europe RedHat is not the leading Linux distributor,
>so please excuse me not knowing your kernel.
>
>-Wolfgang
Hi guys:
I apologize for losing Michael's email yesterday and posting to the list
without cc'ing him. I have Red Hat 6.1, kernel 2.2.12-20, ftape 3.04, and
although I thought I'd solved his problem using mt -f /dev/rft0 setblk 0,
it turns out that if the tape file is large enough, ftape does lose the
location of beginning of tape still. Because of that, it says it cannot
update the header, which is probably what he is seeing(??) ... I was using
dd, not tar, in the case I have, and I may yet retry with straight tar, but
I suspect he's seeing a general problem.
Frankly, I'm tempted to solve it temporarily by writing a tar file to a
large DOS partition, and using a DOS/Windows backup to move it to tape, but
eventually I want to get ftape working again ... I'll let you know if the
straight tar fails using ftape 3.04. I'll also follow your progress to see
what the "unstable" ftape (4.03 ?) leads to ...
Jim
