| TCP/IP (Teil 4): LAN | Diskarchive |

Diskarchive - ADF, ADZ

(Workshop, Teil 1)

Diskarchive, wie sie sein sollen

Die Idee, die hinter Diskarchiven steckt, ist einfach: Man faßt eine ganze Diskette zu einer Datei zusammen. Das ist erstens sinnvoll für Backup-Zwecke, weil Harddisk und Streamer-Tapes wesentlich zuverlässiger sind. Weiters sind in letzter Zeit Diskarchive für Amiga unter anderen Systemen beliebt geworden, und mancheiner von uns Veteranen will bei dem gesteigerten Datenaufkommen mitnaschen.

Die ansprechenste Implementierung eines Diskarchiv-Programms findet sich wahrscheinlich bei Gevatter Macintosh. Dort gibt es MountImage, auf das man einfach eine Diskarchiv-Datei "fallen" läßt, und - schwupps - findet man schon die zugehörige Disk auf dem Finder (dem Apfel-Äquivalent zu unserer Workbench).

So schön praktisch geht es bei uns leider nicht zu. Also ist es Zeit für einen Workshop.

Diskarchive für unsereins

Diskarchive haben am Amiga eine lange Tradition. Schon bevor LHA als das Archiv-Tool etabliert war, kurvten bereits massig DMS-Archive in der Gegend herum. Mit diesen werden wir uns im zweiten Teil beschäftigen.

Später kam FMS dazu, das aber einen etwas anderen Weg geht: FMS-Archive lassen sich nicht nur auf Disketten extrahieren, sondern gleich direkt auf der Workbench mounten. Aus verschiedenen Gründen wurde FMS aber nie wirklich populär, obwohl es unbestritten praktisch ist. Auch das wird im zweiten Teil behandelt.

Heute findet man meistens ADF und ADZ Archive. Deren Existenz verdanken wir der Popularität der diversen Amiga-Emulatoren. Sie sind der Mittelpunkt unseres Interesses im ersten Teil.

Teil drei faßt das Wissen der ersten beiden Teile zusammen, um uns den elendigen CLI und das Usability-Desaster rund um die diversen Programme zu ersparen. Ziel ist es natürlich, das Extrahieren und Mounten auf einen Doppelklick zu reduzieren, damit der Apfel-Mann zumindest nicht mehr über uns lästern kann.

Diskarchive according to Unix-Mann

ADF steht kurz für "Amiga Disk File" und wurde mehr oder weniger "erfunden" von Bernd Schmidt, dem Programmierer von UAE. Wirkliches Know-how steckt aber eigentlich nicht darin, den ADFs sind einfach alle Daten der Disk zu einer langen Wurscht aneinandergereiht. Solche Dateien sind an der Endung ".adf" zu erkennen und haben üblicherweise die Länge von 901120 Bytes (= 880*1024 Bytes = 880K). Dies entspricht der Standardkapazität von Amiga-Disketten.

ADFs sind also nur eine nackte Kopie aller Tracks und Sektoren der Diskette. Es werden keine Vorraussetzungen bzgl. Filesystem gemacht. In weniger Techno-Blabla bedeutet das: Die einzelnen Dateien, die im ADF enthalten sind, sind nicht einfach aufzulisten wie z.B. bei LHA und ZIP, weil nichts über die Directory-Struktur bekannt ist oder vorausgesetzt wird.

Dies ist im Zusammenhang mit UAE durchaus sinnvoll. Hier ist es wichtig, auch Zugriff auf Programme zu erlauben, die ein eigenes Filesystem anstatt einen der Standards verwenden. Gründe dafür gab es (zumindest in den Augen mancher Programmierer) früher einige: damit ließen sich schnellere (aber meist fehleranfälligere) Zugriffe, einfache (und trivial zu überwindende) Kopierschütze und ein paar (aus heutiger Sicht belanglose) Optimierungen implementieren. Der Nutzen hielt sich in Grenzen und der Haupteffekt waren meistens Kompatibilitätsprobleme. Aber genug der dunklen Vergangenheit.

Diese ADFs werden von den Emulatoren "als Disk" angesprochen, und der Programmierer des Emulators muß keine eigenen Zugriffsroutinen schreiben. Stattdessen kann er direkt die Routinen des emulierten Amigas drauf hetzen. Das hebt die Kompabilität des Emulators enorm, weil sich damit viele Inkompabilitäten emulieren lassen.

Aus Gründen des allgemeinen Amüsements beschreiben wir mal kurz das originale transdisk, das mit UAE ausgeliefert wird, um ADFs zu erzeugen: Um z.B. eine Disk in DF1: in ein sepp.adf zu konvertieren, gibt man "einfach" ein:

transdisk >sepp.adf -d trackdisk 1

Und will man das sepp.adf wieder auf DF1: schreiben, braucht man "nur" zu sagen:

transdisk -w sepp.adf -d trackdisk 1

Unnötig zu erwähnen, das transdisk keine wie auch immer geartete Fehlerbehandlung macht und man bei unvorsichtig angegebenen Parametern auch die ersten paar Sektoren der eigenen Harddisk überschreiben kann.

ADZ - ADF komprimiert

Was für einen Emulatorprogrammierer praktisch ist, muß nicht unbedingt angenehm sein für den Anwender. Im Falle von ADF ist das Problem die Größe: 880K sind auch heutzutage eine nicht ganz untriviale Größe, vor allem wenn man sie aus dem Internet laden muß.

Technisch ist die Lösung natürlich trivial: komprimieren konnten wir schon am C64 halbwegs effizient. Die Frage war dann eher, welchen der mannigfaltigen Komprimieralgorithmen man verwendet. Weil bei ADF (zumindest am Anfang) die Unix-Männer das Sagen hatten, wurde gzip gewählt. Das paßte am ehesten zu ihrer Freiheit/Einheit/Brüderlichkeit/Hurra-wir-haben-den-Quellcode Mentalität. Rein technisch ist es nicht nennenswert besser oder schlechter als die meisten anderen gängigen Komprimierer. Die ADFs werden jedenfalls kleiner, und das ist es, was das Volk will.

Findet man daher irgendwo ein sepp.adz, so könnte man folgendermaßen ein sepp.adf daraus machen:

gzip -d sepp.adz

Das kryptische -d könnte man sich als "decompress" merken, wenn man sich sich über gzip irgendwas merken wollte.

Denn es gibt zwar diverse Amiga-Version von gzip, die werden hier aber nicht näher beschrieben, weil es den Workshop sprengen würde. Wer mit ein bißchen guten Willen und Freude am Experimentieren und Rebooten im Aminet sucht, der wird in einer der mannigfaltigen Portierungen schon eine finden, die nicht maßlos viel Stack braucht, halbwegs aktuell ist und sogar ohne spezielle Preferences-Programme und Libraries Amiga-Pfade verarbeiten kann.

Will man umgekehrt aus dem sepp.adf ein sepp.adz machen, so wird es etwas komplizierter:

gzip sepp.adf ; liefert sepp.adf.gz
rename sepp.adf.gz sepp.adz

Eine Eigenschaft von gzip ist nämlich, daß es nach dem komprimieren immer die Endung ".gz" an den Dateinamen dranhängt.

"Buhuu, das könnt ihr doch nicht machen!" haben da natürlich sofort die PC-Männer geschrieen. "Warum nicht, ihr habt's jetzt doch auch so tolle lange Filenamen wie wir?" fragten die Unix-Männer zurück. Da kam die Antwort: "Nicht wirklich, die funktionieren nämlich nur die halbe Zeit, und vor allem in Netzwerken geht da schon mal was verloren im Namen." Also nix ".adf.gz", sondern per Definition ".adz".

Soll uns recht sein, ist in den ersten Teilen des Workshops weniger Tippaufwand.

Jetzt aber richtig

Mancheiner fragt sich jetzt wahrscheinlich, warum ich den ganzen Blödsinn hier erzähle. Naja, es ist immer lustig, wenn man weiß, wie die Dinge passiert sind. Außerdem werden so Workshops länger und literarisch wertvoller.

Der Hauptgrund ist aber zugegeben: das Überlegenheitsgefühl.

Denn jetzt kommt endlich der Teil, wo erklärt wird, wie wir es wirklich machen. Wären das die A-Files, hätten wir folgenden Kasten an den Anfang gestellt:

Täter:	Karl J. Ots
Aktennummer:	4.0.46
Quelle:	aminet:disk/misc/TransADF.lha
Prämie:	Freeware
Anforderungen:	AmigaOS 2.04

Also flux aus dem Aminet geholt und das Archiv extrahiert. Darin findet sich u.a. ein Guide, der erklärt, daß wir nichts zahlen müssen, der Quellcode dabei ist und wie immer wir selbst schuld sind, wenn was kaputt geht. So soll es sein.

Weiters finden sich mehrere Varianten des selben Programmes. Wer will, kann selbst nachlesen, was es damit auf sich hat. Der Rest von uns kann ziemlich bedenkenlos TransADF nach c: kopieren und die anderen beiden Programme wieder löschen. So viel zur Installation.

Damit man die Beispiele selbst ausprobieren kann, haben wir zu diesem Workshop ein sepp.adz dazugegeben. Das Archiv ist komprimiert gerade mal 1K groß und enthält eine Textdatei mit dem Wort "Sepp". Wenig sinnvoll, aber zum Herumspielen gut genug.

Schnell eine leere Disk nach DF0: und folgendes im CLI eingegeben:

TransADF Write Drive DF0: File sepp.adz

Wichtig ist das Write. Die Ausgabe sollte etwa folgendermaßen sein:

Inflating from sepp.adz to trackdisk.device unit 0 (df0:). Starting at track 0, Ending at track 79. Input is a GZip file, decompressing. Inflated: 1004 ==> 901120 Done.

TransADF hat also von selbst erkannt, daß es sich hierbei um ein komprimiertes sepp.adf handelt, und - oh Wunder - es automatisch während des Lesens im Speicher dekomprimiert. Unser originales sepp.adz wurde aber nicht verändert, sonder liegt immer noch klein und schlank auf unserer Platte.

Hätten wir statt einem sepp.adz ein sepp.adf gehabt, so müssten wir in obigen Aufruf nur den File Parameter ändern. Alles andere schnallt TransADF von selbst. So soll es sein.

Und was, wenn wir eine Disk in DF0: in ein ADF konvertieren wollen? Dann lassen wir einfach den Write Parameter weg:

TransADF Drive DF0: File sepp.adf

Hätten wir gerne ein komprimiertes ADZ, was in fast allen Fällen sinnvoll ist, hängt man einfach den Schalter GZip dran:

TransADF Drive DF0: File sepp.adz GZip

Das einzige, was man hier aufpassen muß, ist, daß man selbst dafür verantwortlich ist, daß der gute sepp die richtige Endung erhält. Für TransADF ist es zwar egal, weil es sinnvollerweise nicht auf die Endung achtete, sondern auf die "Kennungssequenz", die am Anfang der Datei gespeichert ist. Aber in Zeiten von Dummkonzepten wie MIME und Windows-Dateitypen sollte man im Sinne des reibungslosen Datenaustauschs daran denken.

Viele ADFs auf einmal

Oft gehören mehrere ADFs zusammen, wenn z.B. ein Programm aus mehreren Disketten bestehen. Die werden dann einfach zu einem Archive zusammengefaßt. Also so in der Richtung wie LHA.

Weil die Hauptzielgruppe von ADFs ja nicht wir Amiga-User sind, wird dazu das ZIP-Format verwendet. Das ist trotzdem eine angenehme Sache, weil es für so ziemlich jede Plattform feine Archivier-Programme für ZIP gibt. Im Unterschied zum bei Unix-Männer beliebten TGZ (vulgo ".tar.gz") funktionieren diese ZIP-Utilities sogar untereinander.

Mehr darüber erfahren kann man auf der Info-ZIP Homepage. Die daraus resultierende Amiga-Version findet man unter aminet:util/arc/U nZip.lha.

Taucht also irgendwo ein sepp.zip auf, kann man folgendes im CLI eingeben:

unzip sepp.zip

Dann finden sich alle darin enthaltenen Dateien fertig dekomprimiert im aktuellen Verzeichnis. Wer vorher wissen will, was drin ist, der kann

unzip -l sepp.zip

eingeben. Das -l kann man sich als Abkürzung für "list contents" vorstellen.

Wie üblich gibt es noch jede Menge anderer CLI-Optionen, die auch in der Unzip-Dokumentation beschrieben werden. Aber das sollte für unsere Zwecke reichen.

Wie geht's weiter?

Im nächsten Teil befassen wir uns mit DMS, einem veralterten und eher zu vermeidenden Format. Nichtsdestotrotz findet man immer noch Archive damit. Weiters lernen wir FMS kennen, damit das dahinschneckende DF0: der Vergangenheit angehört.

Thomas Aglassinger

sepp.adz - Kleines Archiv zum Herumspielen

TransADF.lha - Entpackt und erzeugt ADF/ADZ-Archive

unzip.lha - Entpackt ZIP-Archive