From: fjrei@kbsaar.saar.de (Franz-Josef Reichert)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: A4000-Kritik/CSS (was Re: Animierter Wait-Pointer unter 3.0)
Date: Sat, 21 Nov 1992 11:38:09 GMT
Reply-To: fjrei@kbsaar.saar.de (Franz-Josef Reichert)
 <1992Oct20.094306.28158@arbi.Informatik.Uni-Oldenburg.DE> <9902@cbmger.de.so.commodore.com>
 <jkBUr*Zl0@forge.erh.sub.org> <xtXUr*dm4@kbsaar.saar.de> <g1tVr*0g2@germal.escape.de>
 <lpwWr*wr4@kbsaar.saar.de> <pEd+r*Uk2@germal.escape.de> <fgQ+r*Wx4@kbsaar.saar.de>
 <boI-r*wm2@germal.escape.de>
Organization: Private Amiga Site
X-Newsreader: Arn V1.00 beta rel2

In article <boI-r*wm2@germal.escape.de>, Gerald Malitz writes:

> In article <fgQ+r*Wx4@kbsaar.saar.de>, Franz-Josef Reichert writes:
> > 	Programme dieser Art schossen schon immer auf bewegliche
> > Zielscheiben. OFS->FFS->INTL->DCACHE->[...]. Jede Aenderung war nicht
> > vorauszusehen und konnte den Programmen erst nach ihrem Bekanntwerden
> > "eingetrichtert" werden.
> 
> 	Naah!  OFS, FFS, OFS-INTL und FFS-INTL (von und ueber DCACHE
> weiss ich noch nichts) haben alle verschiedene DOS-Typen, so dass du
> ganz genau weisst, womit du's zu tun hast und dich ggf. schmollend in
> die Ecke verziehen kannst, ganz ohne Schaden anzurichten.  Wenn Du
> natuerlich Software hast, die den Dos-Typ nicht prueft...

	NATRLICH haben diese Programme den DOS-Typ zu prfen!
Aber wie Du selber schon sagst, knnen sie sonst auch nicht viel
mehr tun, wenn sie den Typ nicht untersttzen. So sollte es sein,
und so mu es auch sein. Ich wollte damit nur zum Ausdruck bringen,
da die Definition auf Filesystemebene keineswegs konsistent ist
oder war, und demzufolge auf dieser Ebene herumpfuschende Programme
es auch niemals sein knnen.	

> 	Ueberleg doch mal, was passiert.  Ein Progamm will den ersten
> Block lesen, weil es ja nach dem DOS-Typ schauen will.  Also startet
> es einen IO-Request z. B. mit io_Offset 0 und io_Length 512.  Dein
> Device schreibt dann aber nicht 512 Bytes in den bereitgestellten
> Buffer sondern 512 Bloecke...  Huebsch.

	Ach was,...

| Message-ID: <lpwWr*wr4@kbsaar.saar.de>
| Date: Tue, 03 Nov 1992 09:24:37 GMT
| Oder ueber ein neu zu definierendes Flag zu OpenDevice()
| festlegen, dass alle Angaben als Blockoffsets zu interpretieren sind.

#define	TDB_BLOCKWISE	1
#define	TDF_BLOCKWISE	(1<<1)

	So. fssm_Flags haben wir vor dem ffnen
	
		(a)	berprft
		(b)	einfach nur blind bernommen
		(c)	willkrlich auf Null gesetzt
		
	Bei (a) drften wir jetzt feststellen, da wir nicht
mehr weitermachen sollten. Wissen wir aber von TDB_BLOCKWISE, so werden
alle io_Offset's folglich _nicht_ mehr mit (de_SizeBlock<<2) multipliziert.
Wer (b) macht, erntet jetzt mglicherweise einen wohlverdienten Crash. (c)
ist etwas komplizierter, aber nicht ganz so aussichtslos wie (b):

	Haben wir TDF_BLOCKWISE beim ffnen gesetzt? Sehen Sie, das
Device arbeitet nach wie vor byteweise! Sollte die Multiplikation der
Blockzeiger mit (de_SizeBlock*4) einen berlauf erzeugen, so merken wir
sptestens bei Interpretation von Type, Secondary Type oder Prfsumme,
da irgendwas mit diesem Block nicht stimmen kann. Was man dann immer
noch tun kann, ist innerhalb der ersten zwei Gigabytes Header und
Datenblcke sammeln. Beim Zusammenpuzzeln treten genau die selben
Schwierigkeiten auf, die auch sonst mglich sind: Fehlende, doppelte
oder falsche Blcke.

> 	Tschuess, Gerald.

	Programme, die bei solchen Recovery-Aktionen _schreibend_ 
auf den kranken Datentrger zugreifen, gehren sowieso in den Trashcan.
Wie DiskDoctor eben...	

-- 
Best regards,
Franz-Josef Reichert   GERMANY - VOICE: +49 6805 7417
Kuchlingerstrasse 13   UUCP: fjrei@kbsaar.{saar|adsp}.sub.org
6601 Kleinblittersdorf        fjrei@kbsaar.saar.de
Newsgroups: de.comp.sys.amiga.misc