Defekte Dateien (Files 11) -------------------------- RSX-Workshop, Esslingen 1980 (Update RSX-SIG Treffen, Darmstadt 1981) (Update DECUS-Ungarn Treffen, Sopron 1982) O.Titze, TH Darmstadt 1. Allgemein: ------------- Man wird haeufig mit der Tatsache konfrontiert, dass manche RSX Benutzer schon bei auftretenden einfachen Fehlern beim Zugriff auf ihre Massenspeicher etwas ratlos sind. Deshalb soll gezeigt wer- den, dass man auch mit geringen Kenntnissen ueber die Filestruktur bei fehlerhaften Dateien nicht voellig hilflos ist. Die hier ge- gebenen Details beruhen mehr oder weniger auf experimentell gewon- nenen Erfahrungen, da hier die DEC- Dokumentation keine direkte Hilfestellung gibt, und sind daher auch nicht vollstaendig. Sie wurden unter RSX-11D V6.2, IAS gesammelt, was keine Einschraenkung bedeuten sollte, wohl aber gelegentlich die Nomenklatur beein- flusst. Typische auftretende Fehler sind: -Parity Errors auf RK05 Platten -defekter Home-Block oder MFD -defekte File Header -irrtuemlich geloeschte Files -Parity Errors auf DOS(FLX) Tapes -ueberschriebene ANSI Tapes -irrtuemlich initialisierte ANSI Tapes -alte ANSI Tapes (vor 1976, RSX11D V4) -defekte BRU Tapes (BRU aborts Wuenschenswerte Aktionen: -Patchen der Datenstruktur(gleiches Volume) -Recover einzelne Files(auf ein anderes Volume) -Recover das ganze Volume(kopieren aller Files) Bei den Verfahren wird versucht mit den Standard Utilities auszu- kommen: DMP, ZAP, VFY, PIP Man war auch auf diese Utilities beschraenkt, bevor man mit den da gewonnenen Erfahrungen entsprechende Hilfsprogramme erstellte. So entstanden dan zur Erleichterung des Verfahrens in der Vergangen- heit "ad hoc" einige kleinere Programme DDP Disk Dump und Patch(W. Loew) PARERR Parity Errors beseitigen REC Recover ANSI Tapes(G. Kuehner) RWMTR Read/Write FLX,PRE Tapes DTREC Recover DOS DEC Tapes und benutzen Programme von SIG Tapes PATCH,FIL (inzw. ueberfluessig: PIP /EOF) VOL Home Block Change(bei IAS ueberfluessig: HOM) RECFIL Recover Files ueber File Header BLK,LBN Blockzuordnungen zu Files PAGE 2 Ein Mangel der eigenen Programme ist, dass sie nicht portabel sind. Entweder zu simpel (PARERR) oder benutzen spez. Hardware(DDP) oder der Autor hatte noch keine Zeit alles auszutes- ten(REC). Ihnen liegen aber die im Folgenden genannten Ver- fahrensweisen zugrunde. 2. Platten: Datenstruktur --------------------------- Dabei nur Informationen verwenden, die im folgenden gebraucht wer- den Grobstruktur Index File File Header Directory Files Record Formate Indexfile --------- Block 1 Bootstrap Block LBN=0 2 Home Block LBN=1+256.*N (N=0,1,..) 3 Index File Bitmap File Header: (auflisten mit VFY /LI) *) 4 F-ID:1 INDEXF.SYS 5 2 BITMAP.SYS 6 3 BADBLK.SYS 7 4 000000.DIR (MFD) 10 5 CORIMG.SYS --------------------------------(variabel) 11 6 001001.DIR (UFD's) 12 7 .......... (wobei File ID's 1 bis 5 und alle *.DIR als Eintraege im Master File Directory (000000.DIR) vorliegen) *) VBN der File Header Haengt von der Groese der Index File Bit MAP ab: VBN(File Header)= 2 + + FileID "Index File = Versammlung aller File Header" Index File Bitmap (VBN=3) ------------------------- Fuer interne Organisation des Indexfiles. Gibt an wo gueltige File Header existieren. Dabei gibt ein Bit "n" an, dass der File Header mit F-ID "n" vorhanden ist (bei Block n+3). Bsp.: (W0)=013777 d.h. Bit 11, 13, 14, 15 sind 0 und (File ID = Bit #+1 da LSB = Bit 0!) ergibt: keine File ID's: (12, 13, 14, 15 (10) bzw.) 14, 15, 17, 20 (8) PAGE 3 File Header: ------------ Uns interessierende Groessen in Form eines DMP Ausdrucks: 000 027027 FIL.ID SEQ # 000401 000401 164000 SYS US ATTTYP 020 RSIZ HIGH-VBN EOF-VBN F.FFBY 000000 000000 040 000000 000000 000000 000000 000000 000000 000000 FILE 060 NAME(RAD50) TYP VERS# 000001 030062 040515 034122 100 030460 031466 030067 031060 046460 051101 030070 033061 120 033063 034065 000000 000000 000000 000000 000000 000000 140 000000 001401 146 #W 1.RET-POINT . . . 760 000000 000000 000000 000000 000000 000000 000000 CHKSUM (Adresse im Block/Laenge/Groesse:) Beispiel: 2 (1W) File ID 14 4 (1W) Sequence # 2 14 (1B) H.UCHA User Charact. 0 15 (1B) H.SCHA System 0 16 (1B) F.RTYP Record Type 2 17 (1B) F.RATT " Attribute 2 20 (1B) F.RSIZ " Size 26 56 (3W) File Name (Rad50) ... 64 (1W) Typ ... 66 (1W) Version # ... 144 (1B) Zahl Retrieval Pointer Worte 2 146 (2W) 1. Retrieval Pointer 000000 000563 776 (1W) Checksum 060220 u.U. noch 22 (2W) High VBN 26 (2W) EOF-VBN 32 (1W) F.FFBY Retrieval Pointer Format: Count-1 High Low LBN (4B) Directory-Files --------------- Zur intakten Struktur gehoert, dass es in irgendeinem Directory eingetragen ist. Kein Eintrag = "lost" File Ein Entry (8 Worte) enthaelt neben Namen, Typ, Versions Nr. auch File ID und Sequence Nr. zum Auffinden des File Headers (gelo- eschter Entry nur File ID = 0 gesetzt). FileID Seq.Nr. -- Name(RAD50) Typ Vers# (1W) (1W) (1W) (3W) (1W) (1W) Volume Bit Map -------------- Das File BITMAP.SYS enthaelt ab VBN=2 die Belegung aller Bloecke des Volumes (Bit n=1, Block n ist frei). Fuer ein intaktes Volume muss dies konsistent mit der Information in den Retrieval Pointer der File Header sein. PAGE 4 Einschub: Record Formate von einigen File Typen: ------------------------------------------------ Um die Integritaet eines Files beurteilen zu koennen, muss man ge- legentlich die Datenbloecke selbst ansehen. Dazu muss man die Re- cord Struktur kennen. Record Struktur ist durch (W7) = {F.RATT(B17), F.RTYP(B16)} im File Header festgelegt. Fuer einige typische Filearten sind Attribute und Recordstrukturen im Anhang zusammengestellt. Textfiles haben im allgemeinen folgende Form F.RTYP: R.VAR=1 (variable Laenge) Record Format: {Byte Count} {Daten } mit Attribut (F.RATT): FD.CR=1 Carriage Control Device (File von EDI, TECO/CR) FD.FTN=1 Fortran Carriage Control (1.Zeichen) (Fortran Ausgabe Files) F.RATT=0 Carriage Control im Datensatz selbst (, ) Files von RNO, TECO /-CR, PIP, DMP Fehler im Sinne der File-Struktur --------------------------------- Wie ueberprueft man ob ein Volume fehlerfrei ist? 1.VFY - DEV:/RC liefert die meisten Fehler: Bad File Header, Parity Errors (-4) - DEV:/LO listet "lost" Files und erzeugt einen Entry in [1,3] - DEV:/LI keine weiteren Informationen (Bad File Header) - DEV: Inkonsistenz zwischen Indexfile und Bit Map des Volumes: faelschlich freie Bloecke, lost Blocks, multiple allocated Blocks 2.PIP DEV:[*,*]/LI READ ATTRIBUTES ERROR - NO SUCH FILE " - SEQUENCE CHECK (d.h. wenn auch VFY keine Fehler zeigt koennen immer noch READ ATTRIBUTE ERRORS vorliegen!) 3. DMP ergibt Fehlerdetails PAGE 5 UEBERSICHT: Moegliche Fehler ----------------------------- Diese (sicher nicht vollstaendige Liste) soll einen Uberblick ueber moegliche Fehler geben. 1. Parity Errors (-4) --------------------- Ein Fehler der auf unserer Anlage(8 RK05) haeufig auftritt offen- bar auch im Zusammenhang mit Verschlechterung der Justierung. Fuehrt bei einem File Header Block zu der unverstaendlichen Mes- sage READ ERROR bei einem Ausgabefile! (Lesen des File Header Blocks!) Hier kann nichts gepatcht werden, da Parity durch die Controller Hardware erzeugt wird. Erfahrung: In den meisten Faellen ist die Information im Block noch intakt. Abhilfe: Lesen des Blocks und unveraendertes Rueckschreiben - ZAP fuer wenige Fehler - (sonst eigene Programme DDP; PARERR kopiert ganze Platte und foreign Volumes) 2. "Soft" Errors ---------------- Datenstruktur auf Disk ist intakt, aber Fehler im File System (Memory) liegen vor, aeussert sich z.B.: (i) kein Zugriff mehr zu [0,0] (ii) nach "speziellen" Program-Abstuerzen "FILE -ACCESSED FOR WRTE" Abhilfe: REBOOT System. Wenn das bei (ii) wegen starker System- Aktivitaet nicht sofort moeglich ist, Abhilfe: PIP /NV=FLIE/SR Legt eine neue benutzbare Version an. 3. Scheinbar defekte Files -------------------------- Nichtbeachten der Recordattribute bzw. inkonsistente Benutzung kann zwar zu formal korrekten Files (im Sinne der uebergeordneten Filestruktur) fuehren, die aber nicht verwendbar sind. Beispiele: -Editieren eines Fortran Ausgabe Files (FD.FTN=1, W7=402). EDI(aeltere Versionen) setzt Attribut um in FD.CR (W7=1002), d.h. Fortran Carriage Control geht verloren (Beispiele DOC-Files auf SIG-Tapes), (gilt offenbar nur fuer aeltere EDI Versionen, wie wir sie benutzen) -Editieren (EDI) von RNO-Files, PIP, Directory Files (F.RATT=0) nicht sinnvoll -Einfuegen von Form-feeds(z.B. mit KED) in ein Textfile, welches von einem Fortran Programm erzeugt wurde (FD.FTN=1), zeigt nicht die gewuenschte Wirkung. -RNO Index Output Ueberlauf fuehrt zu Saetzen mit implied Car. Control mit R.SIZ > 132. Folge: LP-Handler druckt nicht weiter, Files nur auf Terminal druckbar. -Inkonsistente Benutzung von Attribut und Recordformat. PAGE 6 Kann zur Folge haben, dass auf LP: nur Leerseiten erscheinen, dagegen das File auf Terminals druckbar ist. Bsp.: BASDOC.DOC (Chicago Tapes) Abhilfe: Umsetzen der Fileattribute mit TECO oder KED z.B.: KED FILE2/CA bzw./-CA,/FO = FILE1 4. Lost Files: TMP-Files ("Marked for Delete") ---------------------------------------------- Files haben ploetzlich keinen Directory Entry mehr. Loesung: VFY /LO PIP [n,m]/RE=[1,3]FILE Waehrend normale Lost Files durch Remove eines Directory Entries entstehen, koennen nach Crashes SCRATCH Files uebrigbleiben FLX.TMP F4PLUS1.TMP etc. die mit OPEN (DISPOSE='DELETE') erzeugt wurden. Zunaechst VFY /LO. Das empfohlene Verfahren: VFY /DE und Loeschen mit PIP; erfordert aber DISMOUNT des Vo- lumes (u.U. Busy) und MOU /UNL Unser Vorgehen: PIP [1,3]*.*;*/DE fuehrt zwar zur Fehlermeldung FAILED TO MARK FILE FOR DELETE gibt aber die allocierten Bloecke frei. Dann PIP [1,3]*.*;*/RM Vorsicht bei Disk Backups: DSC kopiert auch lost Files BRU kopiert diese nicht! Sie sind dann endgueltig "lost". 5. Defekte Directory Files --------------------------- - Alte Files in [1,3] loeschen - PIP [0,0] nm.DIR;1/RM - VFY /LO - UFD [n,m] - PIP [n,m]/RE=[1,3]*.*;* (Es bleibt u.U. ein defekter File Header im Indexfile zurueck) Falls mehrere Directory Files defekt sind, kann es u.U. sinnvoll sein aus einem DUMP der entsprechenden File Header ueber die Re- trieval Pointer(LBN's) die Datenbloecke zu dumpen (MOUNT FOREIGN!), um ueber die File ID eine Zuordnung der Files zu erzi- elen. 6. Inkonsistente Bitmaps ------------------------ BITMAP.SYS stimmt nicht mit der aus den Retrieval Pointern er- stellten Map ueberein. Feststellen: VFY DEV: Standardverfahren: - VFY /UP "freie" Bloecke wieder als belegt markiert - VFY /RE "belegte" " " " frei " PAGE 7 multiple allocated: PIP /DE (am besten alle betroffenen Files, gewisse Chance dass das zuletzt erzeugte File intakt ist) 7. Nicht korrekt abgeschlossene Files ------------------------------------- Haeufig nach "Abort" eines Programms. Feststellen: PIP FILE/FU ergibt Zahl der Bloecke 0./n. Abhilfe: PIP FILE/EOF Frueher wurden hierfuer Programme von den SIG Tapes benutzt. An diesem Beispiel(PATCH, bzw. FIL) soll gezeigt werden,wie diese Programme auf die Information in dem File Header zugreifen. Typischer Ablauf: -zunaechst feststellen ob File locked. Dazu werden die File Attribute gelesen(QIO IO.RAT) und U.CHA=100(locked) geprueft. Falls nicht Zugriff von Write Access wird lock zurueckgesetzt. Dann QIO Write Attributes. -Bloecke feststellen Alle Counts aus den Retrieval Pointers werden addiert. Es er- folgt ein OPEN Update. Die Blockzahl wird in F.HIBK, F.EFBK im FDB eingesetzt. F.FFBY wird falls nicht definiert auf 1000 ges- etzt. -Recordsize Falls nicht R.FIX werden alle Records gescannt, um die maximale Recordsize zu ermitteln. 8. Defekte File Header: ------------------------ Einfache Faelle: (i) wenige falsche Bits gesetzt, Checksum stimmt nicht Abhilfe: DMP File Header, Checksum berechnen, ZAP (Macro Hilfsprogramm fuer Checksum:) MOV BUF,R0 MOV 255.,R1 10$: CLR R2 ADD (R0)+,R2 SOB R1,10$ MOV R2,(R0) (oder Benutzung Programm DDP) (ii) Bit in Indexfile Bit Map noch gesetzt, aber File Header schon geloescht Abhilfe: a)Bit zuruecksetzen --> File loeschen b)File Header auf "existent" patchen(s.u.) Massive Faelle z.B. defekte Retrieval Pointer: ??? 9. Read Attributes Errors -------------------------- Sie entstehen wenn bei einem File mit mehreren Directory Entries (/EN) dieses ueber einen Entry geloescht wurde. Hier koennen zwei Fehlermeldungen auftreten NO SUCH FILE: Hier kann man das File u.U. wiederherstellen (s.u.). SEQUENCE NUMBER CHECK: PAGE 8 Der File Header wurde schon wieder belegt, die Retrieval Pointer sind weg und wahrscheinlich sind die Bloecke bereits bei anderen Files. 10. Regenerieren von geloeschten Files ------------------------------------- Aktionen nur sinnvoll, wenn dies sofort festgestellt wird, d.h. alle WRITE Aktivitaeten unterbunden werden koennen. Tun: Programm RECFIL benutzen Hierbei werden Files auf ein anderes Volume transferiert ohne den Zustand der Orginal-Disk zu veraendern. 10.1 Manuelle Methode -------------------- Das hier jetzt etwas ausfuehrlicher geschilderte Verfahren soll zeigen, wie man dies auch mit einfachen Verfahren erzielen kann bzw. frueher tat und etwas die Zusammenhaenge erlaeutern. Nach Purge oder Delete:keine weitere Aktivitaet auf der Platte, insbesondere kein Schreiben auf die Platte d.h. Anlegen von neuen Files, da sonst u.U. relevante Bloecke, File Header ueberschrie- ben werden koennen und dann nicht mehr zugaenglich sind. Zustand der Platte feststellen ------------------------------ (PIP [*,*]/LI) aber auf jeden Fall VFY /LI. Man erhaelt eine geordnete Liste aller Files nach FILE ID's. Wenn man nicht die File ID's der geloeschten Files kennt, was im allg. der Fall ist sind die geloeschten Files bei den Luecken d.h. den fehlenden File ID's zu suchen. (maximale File ID = Index File Size - 3) Wiederherstellen des File Headers --------------------------------- Die File Header geloeschter Files enthalten noch alle Information Sie unterscheiden sich von den File Headern existierender Files in 3 Worten: File ID = 0 gesetzt (W2) System Indicator = 100000 (W6), genauer H.SCHA=200 (B15) (Es koennte noch H.UCHA gesetzt sein) Checksum = 0 gesetzt (W256.) Um dem System ein intaktes File vorzutaeuschen muss also zunaechst der File Header Block im Index File gepatcht werden. Nehmen wir an das File mit der File ID=n soll wiederhergestellt werden, so ist der Block mit VBN = n+3 zu patchen: File ID = n System Indicator = 0, (H.SCHA=0) Checksum = (zu berechnen) PAGE 9 Das Patchen kann mit ZAP erfolgen. Vorher >MOU DEV:/OVR/UNL >ZAP ZAP> DEV:[0,0]INDEXF.SYS/AB - n:2/n . . . - x (Hierbei ist lediglich das Berechnen der Checksum u.U. muehsam, so dass es sich empfiehlt dafuer ein Hilfprogramm zu haben) Dieses Verfahren ist fuer alle interessierenden File Header Blo- ecke durchzufuehren. Damit sind sie aber fuer die System Utili- ties (z.B. VFY /LO) noch nicht existent. Deshalb ist noch ein weiterer Schritt notwendig. Patchen der Index File Bitmap ----------------------------- Die Bitmap des Index Files befindet sich im INDEXF.SYS, VBN=3. Hier besagt jedes gesetzte Bit, dass das File mit der entsprechen- den ID existiert (Anm.: Gegensatz zu BITMAP.SYS). D.h. die kor- respondierenden Bits der wiederhergestellten File Header muessen = 1 gesetzt werden (Anm.: Der Bitmap Block enthaelt keine Checksum!). Man findet das entsprechende Bit relativ einfach nach der Vor- schrift: nm = File ID ij = nm - 1 i = Byte Adresse im Bitmap Block j = Nr. des Bits (0 bis 7) z.B. File ID = 56 Bit bei: 55 d.h. Byte Adresse 5, Bit 5 (bzw. Word Adresse 4, Bit 15(8) bzw. 13(10)) oder z.B. (W0) 077777 bedeutet File ID = 16 ist nicht existent. Wurden File Header und Index File Bit Map in dieser Art gepatcht so ist das File als sog. "Lost" File wieder existent. D.h. das File ist zwar vorhanden hat aber keinen Directory Eintrag. Dies laesst sich aber beheben. Directory Eintraege ------------------- Ein Lost File mit File ID = n, Sequence Number = m kann in ein Di- rectory eingetragen werden. Durch PIP>DEV:[UIC]NAME/EN=DEV:/FI:n:m, oder aber bei mehreren Files durch VFY DEV:/LO werden die "Lost" Files im UFD [1,3] eingetragen. Hierbei ist zu beachten, dass der File Name aus dem File Header Block entnommen wird. (Dieser Filename braucht mit dem gesuchten File nicht ue- bereinzustimmen z.B. wenn frueher ein RENAME erfolgte(dadurch wurde Name im File Header nicht veraendert) oder aber bei Editier- vorgaengen kann im File Header nur der Name EDITOR.TMP stehen!) Damit sind die Files wieder durch normale Directory-orientierte PAGE 10 Operationen ansprechbar und koennen z.B. auf ein Back Up Medium uebertragen werden PIP>DEV1:FILE.BAK=DEV:FILE. Damit ist allerdings noch nicht gewaehrleistet dass diese Files auch wirklich intakt sind (s.u.)! Zu diesem Zeitpunkt kann noch nicht auf die Platte geschrieben werden, da die Bitmaps noch nicht intakt sind und mehrfach Allocation vorkommen koennte. Korrigieren der Bit MAP's ------------------------- Obwohl auf das regenerierte File zugegriffen werden kann da alle Bloecke ueber die Retrieval Pointer gefunden werden, sind diese Bloecke jedoch fuer das System noch als "frei" markiert, d.h. das entsprechende Bit im File [0,0]BITMAP.SYS ist gesetzt. Man ko- ennte diese Bits jetzt einzeln patchen aehnlich wie bei der Index-File-Bitmap (beachten: Bit gesetzt heisst Block ist frei, die Bitmap faengt in Block 2 dieses Files an). Das ist jedoch besser mit VFY zu erreichen VFY DEV:/UP Dies erzeugt einen u.U. langen Ausdruck (alle Bloecke!) und es empfiehlt sich nicht diesen generell auf das Null Device zu legen , da man aus diesem ersieht ob Bloecke mehrfach allociert sind. Mehrfach Allocation kann insbesondere auftreten wenn man alte File Header Bloecke regeneriert hat deren Daten Bloecke bei nachfolgen- den Schreiboperationen inzwischen anderen Files zugeordnet sind. Die so wiederhergestellten Files sind nicht mehr zu verwenden, da ihre Daten ja nicht mehr existieren. 11. Zerstoerte Plattenstruktur ------------------------------ Zugriffe zur Platte sind unmoeglich, weil z.B. (i) Home Block, MFD defekt (ii) Platte versehentlich neu initialisiert Da im allg. noch die File Header mit ihren Retrieval Pointern in- takt sind, ist es moeglich diese Files zu regenerieren. Man be- nutzt dazu am besten die Programme von den SIG Tape: UICREC, RECFIL Verfahren: Suchen intakter File Header, Sammeln der Bloecke ueber Retri- eval Pointer und Kopieren auf ein anderes Volume. (Im Prinzip sind auch hier wenn man den Fehler genau kennt, manu- elle Patch- Verfahren moeglich.) Vorsicht: Initialisierte Platten !!!!!!!!! Frueher (RSX11M V3.1, IAS V3.0) waren nur wenige Files zerstoert. Der Default fuer /INF bei INI war =16. Jetzt (RSX11M V3.2, IAS V3.1) sind viele Header zerstoert. Die neuen Defaults betragen fuer /INF RK05 = 147, RM02 = 4096 !! PAGE 11 Weitere Komplikationen: INI legt Index File in die Mitte des Volumes(default) DSC legt Index File an den Anfang des Volumes D.h. INI auf eine Platte, die mit DSC kopiert war, zerstoert u.U. eine entsprechende Zahl von Datenbloecken(!), waehrend die File Header intakt(!) bleiben! Ein File-Recovery mit RECFIL kann dann formal fehlerfrei ablaufen, d.h. alle Files werden gefunden, aber die Datenbloecke der wiedergewonnen Files sind dann u.U. zerstoert. 12. Defekter Home-Block, MFD ---------------------------- Es kann manchmal wuenschenswerter sein, das defekte Volume durch irgendwelche Patches direkt wiederherzustellen, als alle Files in- dividuell mit RECFIL auf ein anderes Volume zu kopieren, insbeson- dere dann, wenn keine zweite Platte mit gleicher Speicherkapazi- tate zur Verfuegung steht. Defekter Home-Block ------------------- Dump (DMP) des Home-Block und sorgfaeltige Pruefung, wo eine Fehler vorliegen kann. Es sollten beide Checksums ueberprueft werden. Erste Checksum (bei H.CHK1=74) fuer die Worte 0 -28. und die zweite Checksum (bei H.CHK2=776) fuer den gesamten Block. Ferner ist zu ueberpruefen, ob Index-File Bit Map Size (bei H.IBSZ=0) und Location der Index-File Bit Map (H.IBLB=2) sinnvolle Werte haben, d.h. Dump der Index-file Bit Map und einiger an- schliessender File Header. Oder falls eine falls ein aelterer Backup dieses Volume vorhanden ist, kopieren des Home-Blocks von dort. Defektes MFD(000000.DIR) ------------------------ -Versuche den LBN des File Headers vom File 000000.DIR zu lokalis- eren (Man benutzt den Pointer zur Index-File Bit Map und seine Groesse aus dem Home-Block und addiert die File-ID (=4) um den LBN des File Headers zu bekommen) -Dump des File Headers und Ueberpruefen auf Korrektheit -Lokalisieren des ersten LBN der Datenbloecke des Directory Files mit Hilfe der Retrival Pointer aus dem File Header. -Pruefen ob wenigstens [0,0] einen gueltigen Eintrag hat. Magnetbaender ============= Es soll hier nur kurz auf die Situation bei Magnetbaendern einge- gangen werden, die sich folgendermassen darstellt: I/O Errors in einzelnen Files auf Baendern koennen von DEC Stan- dard Utilities wie PAGE 12 FLX,PIP,PRE nicht bewaeltigt werden. Haeufig ist der Rest des Bandes nicht mehr zugreifbar. (Diese Situation stellte sich uns haeufig bei SIG-Tapes!). In den neueren Versionen von FLX gibt es hier eine Verbesserung durch den Switch /-RW. BRU ist da besser: Meldet Fehler, aber faehrt meistens(s.u.) fort. Aus dieser Situation haben wir eigene kleine Hilfsprogramme er- stellt: FLX Tapes: - Kopieren Blocks/Files von Band nach Band trotz Fehler - Positionieren - Write EOF Marken ANSI Tapes: - Dunp Tapestruktur - Kopieren Band nach Platte von Blocks/Files - Write EOF Marken PRE Tapes: - Feststellen der Fehler - Listen - Kopieren Band nach Band von Files/Blocks - Positionieren - Write EOF Marken Fehler bei BRU-Tapes -------------------- Ernsthafte Fehler in BRU-Tapes, die zum Abbruch von BRU fuehren, bedeuten wegen der komplexen Struktur der BRU-Baender (s. Anhang), im allg. den Verlust des ganzen Volumes. Fuer die Wiedergewinnung einzelner Files wurde ein Hilfsprogramm geschrieben RDBRU - Read BRU Tapes (G. Kuehner) hierbei versucht man ueber Filename und UIC ein entsprechendes File wiederaufzufinden. Es ist damit auch moeglich im Fehlerfall noch volle Directories von BRU Tapes zu erstellen und damit Struk- tur und Art des Fehlers festzustellen. (Das Programm befindet sich noch in der Entwicklung.) Jedoch muss es wegen der hohen Datenkonzentration von BRU-Tapes das Ziel sein, diese als Gesamtheit wiederherzustellen, da ein Re- covery auf der Basis einzelner Files zu aufwendig waere. Hier ex- istieren noch keine Ansaetze in der Form von Programmen aber es sind folgende Strategien denkbar: Fehler in den Directory Sektionen des BRU-Tapes: Entspricht einem "lost" File auf einer Platte, ein Directory-Block muesste dann aus den noch vorhandenen Header-Informationen erzeugt werden. PAGE 13 Fehler in den Datenbereichen: Verlust des entsprechenden Files, aber Korrektur des Volumes durch Anfuegen von Dummy-Bloecken entsprechend der Retrival Pointer aus dem File Header. Fehler in den Header-Bereichen: Bedeutet den Verlust der Information ueber File Attribute. Korruktur des Volumes durch Einfuegen von entsprechend vielen Dummy Headern gemaess der Directory-Information. Zum Vorgehen: Man muesste ein fehlerhaftes BRU-Tape mit TPC auf eine Platte genuegender Kapazitaet kopieren und dann die entspre- chenden Patches vornehmen. Allerdings ist der Aufwand ein derar- tiges Programm zu erstellen nicht gerade gering, und wird wahrs- cheinlich erst dann vorgenommen werden, wenn ein aktueller Notfall vorliegt, bei dem alle anderen Moeglichkeiten versagen. ANHANG: File Formate -------------------- File Attribute und Record Format einiger File Typen 1. Directory Files --------------- W6=0200 U.CON=200 (B14) W7=0001 R.FIX=1 Record: 8 Worte {F-ID}{SEQ }{LEER}{FILE NAME (3W)} {Typ} {Ver } 2. Fortran Direct Access --------------------- W7=1001 R.FIX=1, FD.CR=1 Records enthalten keine Kontrollinformation. Laenge der Datensaetze durch W10 gegeben. 3. Fortran Ausgabe Files --------------------- W7=402 R.VAR=1 FD.FTN=1 Records: {ByCo}{Daten ....} formated binary: {ByCo}{Seg Word}{Daten ....}{0,CHKSM} max 122. Datenbytes Segment Wort=0,1,2,3 (mittleres, Start, End, Single-Segm) PAGE 14 4. Editor erzeugte Files --------------------- (EDI, TECO mit /CR) W7=1002 R.VAR=1, FD.CR=1 {ByCo}{Daten .....} 5. RNO, TECO mit /-CR ------------------ W7=0002 R.VAR=1 Alle Records haben interne Vorschubkontrolle (,) {ByCo}{Daten...} CR,LF ist im Byte Count erhalten! 6. MACRO OBJ (bei Enable ABS) -------------------------- W7=0002 (Bei allen OBJ, TSK) {ByCo}{Daten } 1. Daten Wort Ladeadresse 7. PIP Directory Files ------------------- W7=0002 R.VAR=1, Implied Carriage Control /BR 1.Record: {ByCo}{ Directory bis UIC ByCo=27(8) folgende: {ByCo}{ Daten } ByCo=16(8) /LI, /FU 1.Record {ByCo}{ Directory bis Datum ByCo=50(8) folgende Zeile in 2 Saetzen: {ByCo}{ Name} ByCo=26(8) {ByCo}{restl. Information} ByCo=32(8) bzw. 146(8) 8. VFY --- W7=1002 9. DMP --- W7=0002 Byte Counts: Records 1,2 sind 67, 61 (8) Folgende 103(8) PAGE 15 10. Mag Tape Formate ---------------- 10.1 FLX(DOS) Label Record Datenbloecke N * 512 B EOF Label Record: (14B) Filename(RAD50) (2W) TYP (1W) UIC (1W) Unused/Protect (2B) Date (1W) Unused (1W) 10.2 PRESERV Label Block (1 Block) Boot Block (1 Bl) Preserv Image (1 Bl) Data (N Bl) EOF Label Block Dummy Boot Block Data EOF EOF 10.3 BRU Tape Struktur DEC-Dokumentation: (Etwas duerftig!) Bloecke: Laenge(Bytes) VOL1 80 BOOT HDR1 80 HDR2 80 <-- EOF Marke Control Record 80 BOOT (des Volumes) 512 Home-Block 512 Directory Headers . . Data . . Headers . . Data <-- EOF Marke EOF1 80 EOF2 80 <-- EOF Marke Da diese Information nicht ausreicht, wurde die folgende PAGE 16 Detailinformation durch DUMP von BRU-Tapes gewonnen, d.h. dass sie nicht ganz vollstaendig ist. Directory-Bereich ================= UFD-Record 80 z.B. fuer [0,0] UFD-Record 80 [1,1] Directory-Bloecke n*512 . . UFD-Record Directory-Bloecke (usw.) Von den bei INI erzeugten Files ist nur [0,0] auf dem Tape vorhanden, aber leer! Directory Bloecke sind nur vorhanden, falls das entsprechende Directory File nicht leer ist. UFD-Record ---------- (B0-B3) "UFD" (W2) File-ID (W3) Sequence # (W4) (W5-W7) Filename(RAD50) z.B. 000000 (W10) Typ - "- DIR (W11) (W12) (W13) (W14) (W15) Owner UIC (2 Byte) z.B 401 [1,1] (W16) Protect Code z.B. 1640000 (RWED,RWED,RWE,R) . . Directory-Bloecke ----------------- (entspricht dem Inhalt eines Platten Directory Blocks) File-ID Seq # (S-Lev) Filename Typ Vers # (1W) (1W) (1W) (3W) (1W) (1W) Nach der Directory Information folgt ein Control-Record (80 Bytes) -------------- enthaelt die ASCII-Information HEADHEADHEADHEAD... und zeigt den Beginn des Header Bereichs an. Header-Bereich ============== UFD-Record [0,0] UFD-Record [1,1] Header-Record . . UFD-Record (usw.) PAGE 17 Header-Record ------------- Ein Header-Record enthaelt maximal 8 File Header pro Record (ohne Zusatzinformation) Laenge <= 10 000 = 4096. Bytes Am Ende des Headers Bereichs folgt ein Control-Record (80 Bytes) -------------- enthaelt die ASCII-Information DATADATADATADATA... und zeigt den Beginn des Daten-Bereichs an. Daten-Bereich ============= Hier sind die Inhalte der Files in der Reihenfolge der Directory Eintraege abgespeichert Data-Record Data-Record . Data-Record Laenge: 10000+60 (8) Bytes ----------- Format: (B0-B57) Zusatzinformation (B60 - Daten Bloecke B10060) der Files Die Zusatzinformation (B0 - B57) besteht aus 3-Wort Entries (maximal 8) der Art: File-ID Retrival-Pointer ------ --- --- --- --- Der Retrival Pointer entspricht im Format dem Retrival Pointer eines Disk-Blocks (Count-1(1B), LBN(3B)). Die Retrival Pointer sind aber auf die Blocklaenge der Data- Records umformatiert, d.h. Count-1 <= 7 Falls die File-ID leer ist folgt kein weiterer Entry Beispiel: Data-Record n 20 400 21 30 400 240 22 1000 222 23 0 225 0 ... Data-Record n+1 23 0 226 27 2000 233 26 400 230 0 ... d.h. File-ID = 23 1. Block im Record n bei LBN = 225 2. Block im Record n+1 bei LBN =226 File-ID = 27 5 Bloecke File-id = 26 2 Bloecke Kontrollinformation: In dem nichtgenutzten Teil dieser Zusatz- information im Kopf eines Daten-Records steht in jedem zweiten Record die ASCII-Information "DATADATADATA.." PAGE 18