Diskettenphänomene - amiga-news.de Forum

amiga-news.de Forum > Amiga, AmigaOS 4 > Diskettenphänomene

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

09.10.2008, 19:18 Uhr

uho
Posts: 114
Nutzer

Hallo,

(ja, ich weiß, das Disks Retro sind. Aber deshalb sind wir ja hier, oder ?!)

zuerst sollte ich erwähnen, daß die erwähnten "Probleme" auf ver-
schiedenster Hardware und (natürlich) mit verschiedenen Disketten
nachvollzogen werden konnte.

Bei einer gestern (inzwischen: vor Monaten) durchgeführten aufwendigen
Disk-Rettungsaktion sind mir eine Reihe seltsamer Dinge passiert:

1) XCOPY-Pro-Fehler
-------------------

(kein Versionsstring, 77052 Bytes, von Originaldisk !)

Gelegentlich nutze ich FFSTest (0.11). Obwohl manche Fehler übersehen
werden, meldet es bei mit XCOPY formatierten Disks stets folgenden Fehler:

...
Checking 1 bitmap blocks
1730..1761: C0000000
key 881: allocation error
...
allocated: 2 keys (in 1 extents)
...

In der FFS-Doku kann man dazu folgendes nachlesen:

"key xxx: allocation error"
- bitmap block xxx doesn't match with computed disk allocations"

Dieses Problem tritt unter OFS und FFS auf, jedoch nicht, wenn die
Disk mit dem OS formatiert oder nachträglich mit ReOrg oder
DiskSalv (Validate) behandelt wird.
Es bleibt jedoch bestehen, wenn Files auf die Disk geschrieben werden
(was ja auch mit einer Neuerstellung der Bitmap einhergeht).

Ob ein (erzwungener) OS-Validierungsprozeß das Problem behebt, konnte
ich nicht nachvollziehen, da ein Reset während des Schreibens stets zu
unlesbaren Disks führte. Kann man diesen Prozeß auf saubere Art von
Hand anschieben ?

Da auf einer leeren Disk nur die Boot-Blöcke belegt sind, kann eine
falsche Bitmap eigtl. nur leere Blöcke als belegt kennzeichnen (nicht
umgekehrt). Dennoch sind die Angaben zu freien/belegten Blöcken
bei OS und XCopy identisch (OFS: 836/0K. FFS: 878/1K).
Wenn schon falsche Bitmap, dann müßte da doch ein Unterschied sein, oder ?

Bei XCopy-TNG tritt dieser Effekt nicht auf.

Auch hatte ich in den ganzen Jahren noch nie ein Problem mit ungültigen/
defekten Disks, welche auf XCopy zurückzuführen wären.
Dennoch wäre es interessant, ob es Abhilfe (Patch) gibt bzw. wie "ernst"
die Sache ist.

Nachtrag:

Der o.g. Fehler läßt sich mit DisKey 2.1 reparieren, indem im Block 881
(Bitmap) das LW 55 von 0x3fffffff auf 0xffffff gesetzt und die Prüfsumme
(LW 0) von 0xc000c037 auf 0x0000c037 korrigiert wird.

Außerdem ist mir dabei aufgefallen, daß selbst die Fehlermeldung von
FFSTest fehlerhaft ist - sie zeigt immer nur das obere Wort dieses LWs an...

Seltsam ist auch der angemeckerte Bereich: 1730..1761 wären 32 Blöcke.
Das ist erstens kein ganzzahliges Vielfaches eines Tracks und zweitens
sind das viel mehr Blöcke, als ich Bits geändert habe (0x3f -> 0xff = 2 Bits).
Da sollte eher 1730+1731 stehen...
Auch wenn die LW-Grenzen als Bereich sehen will, wäre stattdessen 1728..1759
logisch - und würde sich (oh Wunder) auch mit der Disk-Größe decken.
Aber bei V0.11 sollte ich vielleicht nicht so kritisch sein :-) .

2) Seltsame Daten auf formatierten Disks
----------------------------------------

Bei dieser Gelegenheit ist mir aufgefallen, daß die Datenblöcke formatierter
Disketten nicht leer sind.
Mal abgesehen von Boot- und Root-Block schreibt XCopy irgendwelche (?)
Daten hinein.

(Einschub: mittlerweile ist klar, daß es Daten von gespeicherten Files
sind (s.u.), die aber auch trotz mehrfachen kompletten
Formatiervorgängen noch erhalten sind.
Einige Blöcke werden aber "genullt".
Formatiert man die betroffenen Blöcke z.B. mit DisKey, bleiben
sie auch nach erneuter XCopy-Behandlung auf 0)

Beispiel:

code:

Block 0: DOS1+ Nullen - OK
 Block 1: Nullen - OK

 Block 2:
 0000: 72616E71 75652E22 0A29290A 0A287365    ranque.".))..(se     
 0010: 74202372 65626F6F 740A2863 61742022    t #reboot.(cat "     
 0020: 4C612069 6E737461 6C616369 F36E2064    La instalación d     
 0030: 6520576F 726B6265 6E636820 332E3120    e Workbench 3.1      
 0040: 68612074 65726D69 6E61646F 2E5C6E5C    ha terminado.n     
 0050: 6E220A20 20202020 22506172 61206163    n".     "Para ac     
 ...
 01D0: 20706F75 7220696E 7374616C 6C657220     pour installer      
 01E0: 6C652057 6F726B62 656E6368 20332E31    le Workbench 3.1     
 01F0: 220A2929 0A0A2873 65742023 696E7472    ".))..(set #intr

Bei AmigaOS dagegen sieht es so aus:

code:

Block 1:
 0000: 444F5381 444F5381 444F5383 444F5383    DOS.DOS.DOS.DOS.     
 0010: 444F5385 444F5385 444F5387 444F5387    DOS.DOS.DOS.DOS.     
 ...
 01D0: 444F53F5 444F53F5 444F53F7 444F53F7    DOSõDOSõDOS÷DOS÷     
 01E0: 444F53F9 444F53F9 444F53FB 444F53FB    DOSùDOSùDOSûDOSû     
 01F0: 444F53FD 444F53FD 444F53FF 444F53FF    DOSýDOSýDOS.DOS.     

 Block 1234:
 0000: 444F5B81 444F5B81 444F5B83 444F5B83    DO[.DO[.DO[.DO[.     
 0010: 444F5B85 444F5B85 444F5B87 444F5B87    DO[.DO[.DO[.DO[. 
 ...    
 01D0: 444F5BF5 444F5BF5 444F5BF7 444F5BF7    DO[õDO[õDO[÷DO[÷     
 01E0: 444F5BF9 444F5BF9 444F5BFB 444F5BFB    DO[ùDO[ùDO[ûDO[û     
 01F0: 444F5BFD 444F5BFD 444F5BFF 444F5BFF    DO[ýDO[ýDO[.DO[.

Der Inhalt ist nicht völlig zufällig, unterscheidet sich aber
von Block zu Block.
Das letzte Byte ist wohl eine lfd. Nr., die von der Block-Nr. beeinflußt
wird - allerdings mit Sprüngen (01/81, 02/82, ...), wobei es einen
Übertrag auf das 'S' von "DOS" zu geben scheint.
Aber wozu das Ganze ? Warum keine Nullen ?

3) Hardware spinnt
------------------

(nicht mehr reproduzierbar)

Wohl mit keiner Logik zu erklären ist das gestrige Versagen
gleich mehrerer externer Disk-Laufwerke:
Dabei wurden beim Schreiben auf eine leere Disk fast immer
Fehler erzeugt - meist bei Block 881-883. Außerdem schrieb
XCopy beim formatieren zufällige Daten (die Disks waren aber
dennoch verwendbar, da die Blöcke ja als leer markiert waren).
Insgesamt habe ich so ziemlich alle Kombinationen aus zwei 1200ern,
zwei DD- und einem HD-LW sowie zwei Netzteilen (1200er + 500er)
und natürlich diversen Disks getestet. Überall das Gleiche.

Die Probleme traten aussschließlich bei den externen Laufwerken
auf, nicht bei den internen !
Da ich ja auch mit dem (stärkeren) A500-Netzteil getestet habe,
kann man eine zu schwache Stromversorgung wohl ausschließen...

Besonders beunruhigt haben mich aber Abstürze, die nur beim
Schreiben auftraten. Oft wurden kurz vorher Pixel quer über
den Bildschirm geschrieben - wohl ein Problem im Zusammen-
hang mit dem Blitter, der ja die Disk-Daten (De)kodiert.
Hat jemand von euch schonmal etwas Ähnliches erlebt ?
Gibt es da einen Designfehler ? Oder kündigt sich da ein
Hardwaredefekt an ?

Jedenfalls hatte ich in den ganzen Jahren nie derartige
Probleme und nach ein paar Stunden war alles vorbei.
Hab' ich vielleicht 'ne Sonneneruption verpaßt ??

Nachtrag: Der Text sollte eigtl. schon vor Monaten eingestellt werden -
entspr. Sonnenwinde müßten also schon 'ne Weile her sein...

Nach soviel Text zusammenfassend die Fragen:

- Hat(te) jemand ähnliche Probleme/Beobachtungen ?

- Gibt es einen Patch für XCopy ?

- Ist bekannt, ob zwischen/in den Blöcken mit Datenresten durch
XCopy sowas wie ein Wasserzeichen hinterlassen wird, um den
Nutzer zu ermitteln ? Ursprünglich war XCopy ja nur direkt bei
Cachet erhältlich und bei Druckern/Kopieren ist das Ausgeben
versteckter Pixel, die Seriennr., Uhrzeit etc. preisgeben ja
leider seit Jahren gang und gäbe...
Für den unbedarften User scheint die Disk ja eh leer, doch schon
ein oberflächlicher Blick mit einem Disk-Editor würde evtl.
Botschaften entlarven. Im Datenmüll wären sie kaum zu ermitteln,
da man die Originaldaten ja i.A. nicht kennt...

- Wie würde man OS-konform das entspr. LW in Block 881 korrigieren
(die Anleitung für die Checksumme hab' ich IMHO noch irgendwo) ?

- Kennt jemand die Gründe und/oder den Algorithmus, mit dem
die Blöcke bei AmigaDOS gefüllt werden ? Warum keine Nullen ?

- Kann jemand bestätigen, daß der durch XCopy erzeugte Bitmap-Fehler
- entspr. meinen jahrelangen Erfahrungen - tatsächlich harmlos ist ?
Einzig in ganz, ganz seltenen Fällen ist mir ReOrg mit Datenverlust
abgeschmiert. Das kann aber auch andere Ursachen gehabt haben und
ein heutiger Test mit einer ziemlich vollen derartigen Disk ergab
keinerlei Probleme.

- Wie stößt man - idealerweise ohne ein Prog schreiben zu müssen -
einen Validierungsprozeß bei einer intakten Disk an ?

Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

10.10.2008, 15:28 Uhr

dandy
Posts: 2553
Nutzer

@uho:
Ähem - könnte es sein, daß
1) Deine Disketten zu alt und somit fehlerhaft sind,
2) die Schreib-/Leseköpfe Deines Diskettenlaufwerks verschmutzt sind
oder
3) die Schreib-/Leseköpfe Deines Diskettenlaufwerks de-justiert sind?
(würde allerdings nicht die Fehler bei allen Laufwerken erklären - es sei denn, jedes Laufwerk hat einen anderen Fehler aus dieser
Liste)

--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih' und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

EDIT:

Als
4) Möglichkeit fällt mir da noch ein - könnte es vielleicht sein, daß Deine XCopy-Disk von einem uralten Bootblock-Virus befallen ist und dieser sich in den Bootblock der Diskette schreibt und so die seltsamen Einträge verursacht?

[ Dieser Beitrag wurde von dandy am 10.10.2008 um 15:32 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.10.2008, 11:56 Uhr

rbn
Posts: 2001
Nutzer

@uho:

Vielleicht würde ein Tausch der Laufwerke helfen, falls die Reinigung und Justierung fehlschlägt.

Ich habe hier noch 100%ig voll funktionsfähige Floppies für den Amiga.

Falls du mal welche brauchst, dann meld dich einfach bei mir per PN oder E-Mail.

rbn

--
Marketing.
Modern.
Mittelständisch.

http://www.rhein-sieg-design.de

[ - Antworten - Zitieren - Direktlink - ]

13.10.2008, 19:16 Uhr

uho
Posts: 114
Nutzer

@dandy, rbn:

Hallo,

ist zwar schön, daß Ihr Euch durch meine umfangreiche Beschreibung gekämpft
habt.
Allerdings sollte dabei klar geworden sein, daß diese aufwendig zusammen-
gestellten Beobachtungen unter keinen Umständen auf Zufällen bzw. verunreinigten
Köpfen beruhen können. Da träten komplett andere und leicht zu erkennende
Symptome auf.
Außerdem werden meine LWs eine jährlich vorbeugend gereinigt und auch sonst
pfleglich behandelt...

Aber irgendwie bin ich auch selbst schuld:
:-(
Um wenig hilfreiche bzw. mir schon bekannte Antworten zu vermeiden, versuche
ich halt die Tests immer so "wasserdicht" wie möglich zu machen - mit dem
Ergebnis, daß die zwangsläufig etwas längeren Fragen nur teilweise gelesen
werden bzw. die Antworten mangels Wissen gleich ganz ausbleiben (s.a. das
immer noch ungelöste Problem mit der vergeßlichen Echzeituhr in meinem A4000D...).

Ein Disk-LW würde ich aber evtl. noch nehmen, da diesen Winter noch
einige hundert Disks zur Analyse/Formatierung anstehen, hehe :-)).
Am besten mit Track-Anzeige...

Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

11.11.2008, 19:42 Uhr

uho
Posts: 114
Nutzer

Diskettenphänomene - Nachtrag (uho, der Alleinunterhalter :-/ )

a) Validierungsprozeß manuell anstoßen:

Mittlerweile habe ich mir das vollständige FFSTest-Archiv herunter-
geladen und entdeckt, daß dort ist ein Prog namens "validate" dabei
ist...

b) XCopy-Fehler

Da ich vor einigen Tagen ein neu erstandenes Disk-LW auf Herz und
Nieren getestet habe, ist mir durch Zufall folgendes aufgefallen:

Der oben beschriebene Effekt, daß der Blockinhalt nach einer XCopy-
Formatierung unverändert ist (aber dennoch physische Fehler erkannt
werden, was ein "Vortäuschen" des Formatierens ausschließt), tritt
_nicht_ auf, wenn mehr als eine Diskette auf einmal und _ohne_ Verify
formatiert wird. Schaltet man das Verify ein, ist der Vorgang auch
bei mehreren Disks wieder fehlerhaft.
Diese Effekt ist (wiederum) unabhängig von den verwendeten Laufwerken.

Will man also die Blöcke einer Diskette wirklich mit Nullen füllen
(z.B. um Daten wirklich zu vernichten oder bei Experimenten mit
Disk-Editoren veränderte Blöcke leichter aufzuspüren), bleiben
nur folgende Möglichkeiten:

1) Formatieren mit XCopy (classic) zusammen mit einer
weiteren Disk und ohne Verify.

2) Vor dem Formatieren erst mit XCopy "Löschen" durchführen;
dann geht auch normales Formatieren mit nur einer Disk
und (zweckmäßigerweise) Verify.

In jedem Fall Extra-Zeit bzw. -aufwand...

3) XCopy-TNG verwenden (ist aber langsamer, umständlicher
& häßlich).

Wem es nur um das Vernichten der Daten geht, kann auch AmigaOS
nehmen - aber mit den beschriebenen seltsamen Blockinhalten
und entsprechend langsamer (die NOVERIFY-Option wurde schon
lange entfernt, leider...)

Soweit dazu. Und wenn Ihr von Bugs noch nicht genug habt: Im "version"-
Befehl habe ich einen ebenfalls heimtückischen Fehler entdeckt -
entspr. Text stelle ich heute ein...

Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

30.11.2008, 18:24 Uhr

uho
Posts: 114
Nutzer

Hallo,

kleiner Nachtrag:

Beim Stöbern in alten Disk-Beständen sind mir noch andere XCopy-Versionen
untergekommen, z.B. eine Version 6.01 (lt. Gfx - ohne Versionsstring).
Da diese sowohl von der Filegröße (ungepackt) als auch vom Funktionsumfang
her kleiner war, ist davon auszugehen, daß es sich um eine ältere Version
handelt. Die Grafik wurde ja gerne mal ausgetauscht...
Diese und auch zwei andere Versionen hatten den beschriebenen Fehler, daß
physikalische Schäden am Datenträger zwar bemerkt, die Bytes aber nicht
verändert werden, ebenfalls.

Komisch, daß diesen Fehler (heutzutage würde man ihn vielleicht als
"ernstes Datenschutzproblem" titulieren) von einer (mindestens)
fünfstelligen Nutzerzahl bisher niemand bemerkt hat...

Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

30.11.2008, 18:57 Uhr

Thore
Posts: 2266
Nutzer

Manche Versionen scheinen auch Probleme mit Turbokarten zu haben.
Am besten sollte man auch X-Copy Versionen mit dem Namen "U.Magen" bzw "Uli Magen" meiden, da dies modifizierte Raubkopien sind.
Ab OS2.x stößt das OS den Validierungsprozess an, sobald sie eingelegt wird, da der Disk-validator im ROM ist, allerdings nur wenn sie auch korrupt ist.
Für eine intakte Disk empfehl ich DiskSalv, da kannst auch validieren.
X-Copy hinterlässt im Grunde keine Spuren auf der Disk (abgesehen vom Gap, der meist Mülldaten enthält und auch bei sogenannten Longtracks eine entscheidende Rolle spielt für kopiergeschützte Software)
Versuch die Disk mal mit dem Format-Befehl zu formatieren (wenn die Daten unwichtig sind), oder mit DiskSalv zu reparieren, wenn das auch nicht klappt, müsste die Disk nen Schaden haben.

[ - Antworten - Zitieren - Direktlink - ]

30.11.2008, 19:20 Uhr

uho
Posts: 114
Nutzer

@Thore:

Hallo,

wie schon ausgeführt, löscht mein XCopy die Daten auch bei
einer kompletten Formatierung nicht.
Man kann dann - z.B. mit AZap - die Blöcke anschauen und sieht
dieselben Daten wie vorher (abgesehen von den Root- u. Bootblöcken).
Nur für den Sonderfall, daß man mehr als eine Disk gleichzeitig
formatiert, findet man dann tatsächlich Nullen.
Ausnahme bildet da lediglich XCopy-TNG.

Für mich war die Erkenntnis, daß sich nicht nur mein Original-
XCopy so verhält, wichtig. Noch besser wäre ein entspr. Patch.

Welche Version hast Du ? Filegröße ?

Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

30.11.2008, 19:31 Uhr

Thore
Posts: 2266
Nutzer

Ich hab X-Copy Professional 1990.
Genaue Version: Zeigt Version nicht an aber Datum von Information ist 24.10.1991
Filegröße: 65156 Bytes

Ich hab auch die Originale eben benutzt um die Daten zu ermitteln, nicht die Sicherheitskopie.

[ - Antworten - Zitieren - Direktlink - ]

05.01.2009, 18:48 Uhr

uho
Posts: 114
Nutzer

Hallo,

die letztlich in A-News angepriesene XMas-Version hat denselben Bug,
d.h. sie formatiert auch nicht wirklich.

Ob zusätzlich die Bitmap falsch ist habe ich nicht getestet, da
ich das Archiv vor Frust gleich wieder gelöscht habe...

(jetzt teste ich erstmal die "Ändern"-Option B-) )

...da ja außerdem Gfx & Font häßlich waren und außerdem mind. ein
(kleiner) Bug hinzugfügt wurden (fehlender Doppelpunkt in der
Zeitangabe)

Gruß

uho

P.S.: Frohes 2009 !

[ Dieser Beitrag wurde von uho am 05.01.2009 um 18:53 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.01.2009, 19:30 Uhr

Thore
Posts: 2266
Nutzer

Tritt das Problem bei Turbokarten auf?
Hast Du die Möglichkeit X-Copy auf nem 68000 laufen zu lassen?
Nur so ein Gedanke, ich glaub ich hatte was in Erinnerung daß bei Turbokarten es Probleme mit X-Copy kommen kann, bin mir aber nicht mehr so 100%ig sicher. Aber ausprobieren kostet ja nichts.

[ - Antworten - Zitieren - Direktlink - ]

16.01.2009, 16:25 Uhr

uho
Posts: 114
Nutzer

@Thore:

Habe es auf '020, '030 und '060 getestet (sowohl mit als auch
ohne Fast-RAM) - überall mit demselben Ergebnis.
Verhält sich auch sonst nicht anders als auf einem A500 (den ich
jetzt nicht extra hervorgekramt habe), so daß anzunehmen ist,
daß der Bug vom Prozessortyp unabhängig ist...

Gruß

uho

[ - Antworten - Zitieren - Direktlink - ]

17.01.2009, 21:42 Uhr

Ramiga
Posts: 1
Nutzer

Hallo, ich bin neu hier und habe einen Amiga zu verschenken. Dann noch einen Klappbox mit Disketten. Wo und wem kann ich soetwas anbieten?
Wegschmeissen kann ich das ganze immernoch, falls es keiner will.

Gruß Ramiga

icq: Ramiga 166590265

[ - Antworten - Zitieren - Direktlink - ]

18.01.2009, 18:12 Uhr

ZeroG
Posts: 1487
Nutzer

@Ramiga:
Setz das doch bitte hier im Forum in die Kleinanzeigen.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Amiga, AmigaOS 4 > Diskettenphänomene

[ - Suche - Neue Beiträge - Registrieren - Login - ]