🚀 go-pugleaf

Moin !

mike@cochise.pcs.com (Mike Schroeder) writes:
>lehners@uniol.UUCP (Joerg Lehners) writes:
>->Wo's mir 'mal grad wieder auffaellt:
>->Ein 'kleiner' Bug in der Streamer-Software.
>->[...]
>das wundert mich, denn Streamer einlegen und "</dev/ris0" tippen ist
>fuer mich automatisch; spaetestens wenn mein Prompt wieder da ist,
>weiss ich, dass der Streamer zurueckgespult ist (was Du ja wohl auch
>bezwecken willst).

Eben dies macht der Streamer bei uns nicht. Alle betroffenen Kisten sind
32 Bitter mit dem CTS1(a) Laufwerk und Munix V.3-3.1.
Das 'Warten auf Zurueckspulen' wird eben erst beim zweiten Kommando
der Art gemacht.
Wie Stefan Stabelberg ja schon geschrieben hat, scheint der Fehler
nicht mit dem CTS2(a) Laufwerk aufzutreten.

>->Wenn man waehrend des Zurueckspulens auf den Streamer schreibt, dann
>->ist mit ziemlichen Datenverlust zu rechnen.
>->Wenn man waehrend des Zurueckspulens vom Streamer liest bekommt man
>->nur Unsinn.
>Ich muss zugeben, dass ich sowas noch nie probiert habe (welchen Sinn
>soll das denn haben ?-), aber ich kann es ja mal ausprobieren!

Ganz einfach: ein alltaeglicher Vorgang:
Streamer in die Luke und Luke schliessen;
sofort wird danach 'find blafasel -print | cpio -ovS > /dev/nris0'
eingegeben.
Weil der Streamer aber meist nach dem Einlegen noch am Rueckspulen
oder positionieren ist, gibt's nur Muell auf dem Band.

Ich hab's just grad noch 'mal ausprobiert: das Kommando oben macht
zwar den *Eindruck* als wuerde es auf den Streamer warten (bis der
zurueckgespult ist) und schreibt erst dann auf das Tape. Tatsaechlich
ist aber der erste Block (60 BK bei der 'S' Option) futsch.
Je nach Groesse der Dateien printet das cpio Kommando ein paar
Dateinamen aus und wartet dann, wenn der Streamer fertig ist, gehts
weiter.

>->Unsere Kisten laufen unter Munix V.3-3.1.
>->Ist der Fehler bekannt, und eventuell in V.3-3.2 behoben ?
>erster Teil: bisher nicht, wir machen das allgemein so (s.o.)
>zweiter Teil: muss ich mal probieren.
>Ich melde mich wieder

Es waer echt nett, wenn dieses 'Odditity' bald der Vergangenheit angehoert.
Ich hab' mir zwar bisher erst einmal dadurch ein paar Dateien zerschossen,
aber es kann schnell wieder vorkommen, wenn man zu schnell ist ...

  Bis denn
	Joerg
--
/ UUCP:    lehners@uniol              | Joerg Lehners                  \
|       ...!uunet!unido!uniol!lehners | Fachbereich 10 Informatik ARBI |
| BITNET:  066065 AT DOLUNI1          | Universitaet Oldenburg         |
\ Inhouse: aragorn!joerg              | D-2900 Oldenburg               /