Bemerkungen zum Mass Downloading

von Wolfgang Näser, Marburg 6/2000 ff.

Ebenso revolutionäre wie nützliche Retrieval-Plattformen bieten die sog. Mass Downloader. Inzwischen existieren hierzu mehrere Programme. Sie erschließen komplette Web-Sites oder definierte thematische Bereiche und ermöglichen so eine Art Website-Dokumentation und / oder die Anlage wissensbasierter Infosysteme (Knowledge Bases) mit regelmäßigen Updates. Vor allem im Pressewesen und im wissenschaftlichen Bereich sind Mass Downloader und die von ihnen gebotenen vielfältigen Arbeitstechniken eine wertvolle Hilfe.

Ich dokumentiere im folgenden die seit Anfang Juni 2000 gemachten Erfahrungen. Es geht nicht darum, alle Features und Möglichkeiten der Programme aufzuzeigen, sondern vor allem Probleme und Lösungsmöglichkeiten beim Umgang mit großen Dateimengen: pro Laufwerk können durchaus 300.000 oder mehr Files anfallen, und die wollen störungsfrei und effektiv verwaltet werden. Außerdem geht es darum, auf der Basis eines Bulk Retrievals später thematische Module und Algorithmen für ein virtuelles Lernen zu entwickeln.

I. Offline Explorer  (OE, derzeit V. 1.4)
Als Projekt definieren Sie eine Adresse (z.B. www.welt.de als URL oder www.hr-online.de/allgemein/technik/ als definierten Pfad), von der Sie alle zugehörigen Dateien (also auch Bilder, Animationen, Audio-Samples, Videos) bis zu einer gewünschten (hierarchischen) Ebene retrieven können; der OE öffnet optional bis 100 Zugangspfade parallel (multi channel retrieval) und springt als "automatischer Infonaut" zwischen den gewählten URLs hin und her, um ohne Pause dort "einzusammeln", wo es gerade geht. Je nach Geschwindigkeit, Festplattengröße und Arbeitsspeicher können, wenn Sie an einem LAN arbeiten, in einer Stunde 200 MB (oder mehr) an Daten hereinkommen, die so angeordnet werden, daß die URL auch off-line simulationsgerecht 'abgesurft' werden kann. Dafür entstehen allerdings spezielle Directory-Strukturen mit möglicherweise Windows-inkompatiblen sehr langen und komplizierten Pfad- bzw. Dateinamen, die ein Abspeichern der so gewonnenen URL-Struktur auf CD-ROM nur eingeschränkt erlauben mit dem Resultat, daß von dort aus nicht mehr alle Pfade off-line zugänglich sind. Sie müssen dann mit einem alternativen Offline-Browser/Searcher, z.B. LIKSE32(tm), das Projekt nach bestimmten Daten durchsuchen.

Arbeiten Sie mit 32-Bit-Modemverbindung (über TP WinSock 4.0), so sollten Sie mit dem Offline Browser zunächst

(und jeweils nicht mehr als 10 Parallel-Channels) retrieven, damit nicht zu viele Dateien in die Warteschleife (Queue) kommen, sonst könnte sich der Rechner nach ca. 50 MB 'aufhängen'. Das (auch geschwindigkeitsabhängige!) Verhältnis von Download- zu Queue-Dateien sollte 1:1 nicht übersteigen; bei optimaler OE-Konfiguration (kluge Datei-Auswahl; Download nur von der Domain oder vom Start-Directory; nur so viel Parallel-Pfade wie möglich) können Sie erreichen, daß auch bei größeren Dateimengen (z.B. 10.000 oder mehr) die Queue einen Wert von 1000 nicht überschreitet und zwischendurch möglicherweise auf "0" geht. Sie können auch portionsweise arbeiten und nach einer bestimmten Zeit das Retrieval anhalten (suspend), dann werden noch alle angefangenen Ladevorgänge abgearbeitet; hernach können Sie entweder das Projekt komplett stoppen oder - ggf. mit eingeschränkten Optionen - das Retrieval fortsetzen (resume).

OE-Retrieval-Rechner sollten großzügig dimensioniert sein. Sie benötigen mindestens 32 MB (Win 95) bzw. 64 MB (Win 98) RAM, min. 150 MB Platten-Platz für das Swapping und weitere 150 MB zum Speichern Ihrer Retrieval-Daten. Mit einer solchen Mindestausstattung können Sie kleinere Projekte erarbeiten und diese später auf CD-R sichern. Beim Retrieval sollten Sie die Zahl der parallel gespeisten "Empfangskanäle" bzw. sonstigen Optionen möglichst einschränken und rechtzeitig den Vorgang abbrechen.
Vor der CD-Sicherung löschen Sie alle *.tmp und defragmentieren Sie die Platte. Größere Projekte erfordern mehr RAM (min. 128 MB) und Platten-Platz (min. 8 GB); der Speicher muß frei sein, deshalb Neustart! Bei Joliet-kompatiblem CD-Burning (Optionen checken!) sind für den Aufbau des sog. Recording Image zunächst alle Dateien einzulesen, was möglicherweise stundenlang dauert und mehrere hundert MB beansprucht, die in einem durchgehend freien Bereich verfügbar sein sollten, damit das Einlesen ruckfrei und zügig verläuft und hinterher möglichst schnell (z.B. 4-Speed) geschrieben werden kann. Stockt das Image-Einlesen beim Brennen, entsteht der gefürchtete buffer underrun und ist der Rohling verdorben. Größere Projekt-URLs sollten Sie immer per single session auf getrennten CDRs sichern. Überschreitet der Projekt-Umfang 650 MB, so müssen Sie (bis 730 MB max.) auf eine Long-Play-CDR sichern oder mehrere CDRs verwenden, deren Pfadstruktur Sie so einrichten, daß jede Subthemen-CD autonom abgesurft werden kann (Näheres s. unten).

Größere OE-Projekte erzeugen (besonders bei maximalem multi channel retrieval) sehr viele *.tmp-Dateien: 8.000 oder mehr, die einen Umfang von > 300 MB ausmachen können. Bei optimalen Bedingungen (Parsing beendet, Queue leer, nichts mehr zu empfangen) werden alle flüchtigen Dateien aus \windows\temp und \oe\queue automatisch entfernt; anderenfalls sollten Sie sie löschen, bevor Sie auf CD sichern. Scheitert die Sicherung, so müssen Sie ebenfalls \tmp freimachen (weil sich hierin ca. 400 MB aus dem recording image angesammelt haben können), ggf. die Platte defragmentieren und das System neu starten.

Wie angedeutet und in (4b) dokumentiert, können Sie ein zielgerichtet angelegtes Projekt jederzeit neu öffnen und Ihren Datenbestand durch aktuelles Material und neue Datei-Typen erweitern. Achten Sie darauf, daß nicht versehentlich (intakte) vorhandene Dateien erneut geladen und damit überschrieben werden. Starten Sie OE, so wird zunächst das Projekt auf Vollständigkeit hin inspiziert und im Parsing geprüft, ob irgendwo (Nach-)Lade-Bedarf besteht. OE "scannt" dazu eine projektbezogene *.map-Datei, die im Programmdirectory eingerichtet wurde und entsprechend gewachsen ist. Diese Datei, die bis 8 MB (!) oder größer werden kann, enthält jeden projekt-eigenen Lade-Zugriff. Sollte *.map versehentlich gelöscht werden, beeinträchtigt das die neue Session nur insofern, als *.map neu angelegt wird und die Altbestands-Durchsicht langsamer verläuft. In beiden Modi wird zwischendurch Neues hinzugeladen und ggf. in Abständen die Queue aufgefüllt und entladen. Je größer das Projekt (s. unten), desto speicher-intensiver (und schwerfälliger) das Updating. Da auch beim dritten oder weiteren Projekt-Update noch viele MB an Daten hereinkommen können, sollten Sie Geduld aufbringen und warten, bis die Queue leer und das Parsing abgeschlossen ist, bevor Sie das Programm schließen. Ist ein Parallel-Tasking (Kontrolle mit WinCmd, s.u.) nicht mehr möglich und ist absehbar, daß sich eine größere Queue nicht mehr verringert, sollten Sie den Prozeß abbrechen, den PC ordnungsgemäß herunterfahren und neu starten, damit die möglicherweise ungewöhnlich hohe, in sechstellige Dimensionen angestiegene Dateien-Zahl noch verwaltet werden kann.

==> Lädt an einem LAN der PC so schnell (oder baut sich aufgrund einer Zeitdifferenz zwischen Parsing und Download eine so große Queue auf), daß Sie Schwierigkeiten haben, ins Programm einzugreifen oder es zu beenden und besteht die Gefahr, daß sich der PC so "aufhängt", daß Sie ihn nicht ordnungsgemäß herunterfahren können und ggf. einer der berüchtigten "Schweren Ausnahmefehler" ansteht, so ziehen Sie als Notbremse den LAN-Stecker heraus und warten Sie, bis 1. in der unteren Status-Zeile "Speed: 0 bps" erscheint und 2. die oben angelegten Programm-Felder Exit, Edit, View, Download, Help wieder anklickbar sind. Klicken Sie auf Download / Stop All /Yes und verlassen Sie den Offline Explorer. Alle aus dem Retrieval für unvollendete Prozesse angelegten *.tmp (s. oben) werden nun in \oe\queue und \windows\temp gelöscht (und sind damit als Basis für eine spätere Wiederaufnahme des Retrievals verloren).

Im folgenden dokumentiere ich einige größere OE-Projekte, die mit verschiedenen Konfigurationen und Strategien seit Anfang Juni 2000 durchgeführt wurden:

(1) Mit P II/300, 64 MB RAM, HD (EIDE, Western Digital) 8 GB, Brenner Traxdata 4120: In Haupt-Session mit LAN-Anbindung ca. 32.000 Files geladen und aus anderen Sitzungen weitere 20.000 zugespielt, so daß für dieses Projekt insgesamt 53.257 files anfielen, das entspricht netto 490,4 MB, für die jedoch beim single session burning mit dem Easy CD Creator 4.02c brutto 518 MB benötigt werden. Infolge des Retrievals war eine hochkomplizierte Baumstruktur mit vielen Subdirectories entstanden, von denen eines in wiederum zahlreichen weiteren Sub-Directories den Löwenanteil der Dateien beherbergte. Alle Dateien konnten mit Quad-Speed unter dem Programm Easy CD Creator de luxe 3.50c auf einer handelsüblichen CD-R gesichert werden. Der Versuch, die CD-R zu kopieren, gelang nur bedingt: zwischen der TOC und dem eigentlichen Nutz-Brennraum bildete sich (softwarebedingt, wie erkannt wurde) ein schmaler leerer Zwischenring, allerdings konnte nach einigen Lade-Mühen die CD-R gelesen werden.

(2) Am 23.6.2000 Retrieval der kompletten Domain einer großen Wochenzeitung, bis ca. 700 MB an Daten und ca. 70.000 Files geladen waren. Diese mußten auf einem 80-Minuten-Rohling (700 / 730 MB) gesichert werden, was nur mit dem Programm NERO 5.03 gelang: Modus disk-at-once, no caching, single oder double speed. Schalten Sie bei NERO allerdings die Dateioption "Joliet" aus, so werden die gespeicherten Pfadnamen verändert (z.B. wird staff-www.uni-marburg.de zu STAFF_WWWUNI_MARBURGDE), das simulierte Absurfen des gesamten Projekt-Datenbestandes von der Platte aus wird unmöglich; für bestimmte Detailínformationen müssen Sie das gesamte Projekt-Directory mit dem Utility LIKSE(tm) absuchen.

(3) Für weiter(gehend)e Versuche wurde am 26.6.2000 der beschriebene PII-Rechner auf 192 MB RAM hochgerüstet; Resultat: ruhigeres Retrieval ohne ständiges Festplatten-Swappen, kontrollierter Programm-Ausstieg und sogar Parallel-Tasking möglich.

(4a) Mit dieser neuen Konfiguration wurden am 7.7.2000 aus der Domain einer mit ungewöhnlich viel Bild-Material aufwartenden populären Tageszeitung insgesamt 45.027 Files in 477 MB empfangen; einen derart großen und in einer hochkomplizierten Baumstruktur angeordneten Datenbestand auf CD-R zu sichern stellt sehr hohe Anforderungen an Hard- und Software und erfordert spezielle Vorgehensweisen. Ferner muß mit einer relativ langen Einlese-Zeit (bis 30 Minuten oder mehr) gerechnet werden, wenn die CD im DOS-kompatiblen Joliet-Format beschrieben wird (ist mit NERO ebenso möglich wie mit dem Easy CD Creator). Um nach mehreren zeitaufwendigen Fehlversuchen (5 Rohlinge fehlbeschrieben) weitere hardware-bedingte auszuschließen, wurde der Retrieval- und Sicherungsrechner mit einer zweiten, etwas schnelleren und neueren Festplatte (EIDE, Fujitsu Picobird 10 GB, Slave 1) versehen, die als Laufwerk D:\ alle Retrieval-Daten und auch das Swap-Directory \tmp aufnehmen sollte (das Swappen der D:\- Daten auf C:\ hatte sich als ungünstig erwiesen). Die in einem anderen Rechner systembedingt mit nur 8,2 GB betriebene Platte mußte zunächst gelöscht werden (alles noch Verwendbare wanderte auf C:\), wurde dann mit FDISK auf die volle Länge von ca. 10 GB re-partitioniert, reformatiert und (unter Win 98) mit den zu sichernden Retrieval-Daten (ca. 80.000 Files) bespielt. Da bei Nero 5.09 Probleme mit der Joliet-Kompatibilität auftauchten und Adaptec's neuer Easy CD Creator 4.02 entweder hakte oder (mit Double Speed) in zwei erfolgreich scheinenden Versuchen lediglich die Hälfte der MB-Summe aufzeichnete (und dann mit Ctrl-Alt-Del gestoppt werden mußte!), gelang es (nach rund zwei Tagen!) nur mit dem Easy CD Creator de luxe 3.5c, alle 45.027 Files in korrekter Pfadanordnung und lese-sicher auf einem konventionellen Rohling zu sichern (tatsächlich erwies sich auch in anderen Fällen dieses Programm als einziger "Rettungsanker", wenn OE-Projekte mit tiefgestaffelten und von Datei-Typen und -benennungen her kritischen Baumstrukturen zu sichern waren).

(4b) Am 10.7. wurden zum Tageszeitungs-Projekt (477 MB) noch weitere ca. 254 MB hinzugeladen; die neue Projekt-Gesamtmenge würde eine 88 Minuten Länge entsprechende Überlang-CDR erfordern - die es jedoch bislang nicht gibt: hier würde sich ein DVD-R-Brenner empfehlen oder das Aufteilen in 2 CDRs, wie oben beschrieben (Traxdata plant allerdings, im 3. Quartal 2000 eine 99-Minuten-CD-R mit 870 MB Kapazität einzuführen).

Am 11.7. weitere 700 MB (netto unallokiert) hinzugeladen (nach anfangs zögerlichem Parsing ein heftiger Ansturm von Neuzugängen); Queue max. 12.000 Dateien, wurde im Laufe des Retrievals bis auf "0" abgearbeitet; die Map-Datei (s.o.) wuchs auf 8.102.145 Bytes. Der Umfang des Basis-Directorys www.bild.de erhöhte sich auf  1.212.164.606 Bytes, die nur noch als ZIP (= 710.054.076 Bytes) mit Nero gesichert werden konnten. Die peripheren Pfade beanspruchen zusammen rund 392 MB mit 27.693 files; insgesamt dürften mindestens 100 k Files im Projekt enthalten sein (darunter in \ivw *) 450 MB mit tausenden von Kleinst-Dateien unter 100 Bytes in meist separaten Directories, was das Auszählen und Sichern des Datenbestandes sehr langwierig gestaltet). 12.7.: weiteres Update (> 165 MB; Map-Datei > 10 MB; Ges.-Datenbestand ca. 150 k Files); dann Löschen von \ivw, Stamm-Directory jetzt 1,29 GB; Defragmentieren der Platte D:\.
Der (wie in [3] und [4] beschrieben aufgerüstete) P II/300 stößt hier an seine Grenzen, und man könnte es für bedauerlich halten, daß ein auf der Festplatte einwandfrei funktionierendes derartiges Groß-Projekt nicht so als Ganzes auf einem preiswerten externen Datenträger "verewigt" werden kann. Nun jedoch kommt es darauf an, praktikable Strategien zu entwickeln, um mit vertretbarem Aufwand die enormen Datenmengen eines Großprojekts zu verwalten. Die Analyse des hier herangezogenen "BILD"-Servers zeigt zum einen streng hierarchische Staffelung und mustergültige Ordnung; zum anderen, daß hier bestimmte Themenkomplexe als Archivalien, Bild- und Textserien modular aufgebaut sind: so, daß jedes dieser Module (mit Dateien wie body.html, mainframe.html u.a.) separat aufrufbar ist und eigenständig funktioniert, ohne daß zentrale Link-Mechanismen zu bemühen sind. Ergo ist es möglich, diese Module einzeln zu erforschen, zu ergänzen und (besonders, wenn sie sehr viele Kleinst-Dateien enthalten und es angezeigt ist, die FAT zu entlasten), auf getrennte CD-Rs zu sichern; also kann die Festplatte als letztendlich "flüchtiger" Datenträger in Abständen von nun überflüssigem Material befreit und für neue Retrievals genutzt werden.
*) zur Entstehung der \ivw-Pfade siehe: "Richtlinien für die Kontrolle von Online-Medien" (Nachtrag 31.8.2k)

(5) 13.7.2000 p.m.: www.uni-greifswald.de; (netto) 1.26 GB, 33 k Files, Queue bis ca. 3.000 in rund 3 h 15' (!); [abends] Einbau einer weiteren Festplatte: Fujitsu Picobird (EIDE) 27 GB (=Master 2), eingerichtet als erweiterte Partition mit 4 logischen Laufwerken (3 [E,F,G] à 7 GB, 1 [H] à 5 GB) mit dem Vorteil, daß (unter FAT 32) hier auf 7 GB in 4-kB-Clustern immerhin 1.789.743 allocation units verfügbar sind, während D:\ als durchgehende 10-GB-Partition in den doppeltgroßen 8-kB-Clustern nur 1.247.818 AUs bereitstellt. Danach (innerhalb von 3 Std.) Moven aller OE-Projektdaten von D:\ (hier 4.5 GB) auf E:\ (hier zus. 984.590 AUs in nur 3.9 GB, d.h. durch die kleineren Cluster 600 MB an Platzgewinn). 14.7.2000 weitere Daten (auf E:\) hinzugeladen. Projekt später auf 2 CDs gespeichert, die jeweils (vom Stamm-Directory aus) autonom abgesurft werden können.

(6) Div. andere Projekte in Größenordnungen von 500 MB bis > 1 GB (mit bis zu ca. 50 k Files), jeweils auf CD-R archiviert, wobei - je nach Projekt-Anordnung (Baumstruktur, File-Typen) - zu entscheiden war, ob ECDC4 oder der Version 3.50c zur Anwendung kam. Falls (z.B. mit ECDC4) das Datei-Einlesen immer langsamer wird und am Ende des Schreibvorgangs noch vor Abschluß des Finalizings selbst bei 192 MB RAM und > 5 GB Swap Space der PC hängen bleibt, ist das nicht zwingend ein Indiz für Konfigurations- Programm(modul)- oder Datenträgerfehler; man darf hier nicht verzagen und muß auf ein etwas weniger aufwendiges Brenn-Programm ausweichen (hier: ECDC 3.50c, s. o.), das (noch) in der Lage ist, "exzentrische" Datenstrukturen zu verwalten und lese-konform zu sichern.
Abgesehen davon, daß im neuen Jahrtausend mehr und mehr dazu übergegangen wird, Archiv-Files nur noch gegen Bezahlung (z.B. 40 Cent / Stck.) verfügbar zu machen, lassen extrem umfangreiche und verästelte Info-Server nur begrenzte OE-Retrievals zu: eine unter FAT 32 erstellte Partition mit 4-kB-Clustern erlaubt "nur" max. 21844 Files pro Pfad. Ist dieser randvoll und fallen weitere Dateien an, so ist anhand einer größenbezogenen Analyse zu entscheiden, welche - oft irrelevanten - Kleinst-Texte oder -Bilder gelöscht werden können, um dem aktuellen Zuwachs Platz zu machen. Die zu löschenden Files sollten jedoch vorher gesichert werden (*.zip), um in einem möglicherweise verbesserten File-System wieder nutzbar sein zu können.

Zum Löschen größerer OE-Projekte

Es ist immer eine sehr speicher- und rechenintensive Arbeit, die vielen Dateien eines großen OE-Projekts von der Festplatte zu entfernen, zumal wenn diese mit FAT 32 formatiert ist. Fallen 50.000 oder mehr Dateien an und befinden sich diese in einer tiefgestaffelten Pfadstruktur, so kann der Löschprozeß bis zu einer Stunde oder mehr dauern und die Hardware (Festplatte) umso mehr beanspruchen, wenn wenig RAM verfügbar und die Festplatte langsam ist. Sie müssen entsprechend vorgehen und ggf. in mehreren Schritten löschen.
I. DOS-basiert: Rückstart auf DOS-Ebene; [zum Plattenschonen] smartdrv.exe laden mit Maximal-Option "/35000", deltree <Directory>. Es dauert dann möglicherweise 30 Minuten (oder mehr), bis alle Files gelöscht sind. Danach Neustart und auf Win-Ebene Defragmentieren mit dem Diskeeper.
II. Win98-intern: Gehen Sie im Explorer (oder besser Windows Commander) in das Projekt-Directory (z.B. www-umr = Domain Uni Marburg); tippen Sie auf der Befehlszeile deltree *.*; Sie müssen dann bei jedem Subdirectory mit j(a) oder y(es) bestätigen; die Subdirectories werden schneller gelöscht. Dann Defragmentieren wie (I).

Wie mächtig der OE ist, erkennen  Sie erst nach einigen Wochen intensiver Arbeit; mit diesem Werkzeug können Sie ganz gezielt Wissensdatenbanken (knowledge data bases) anlegen, wenn Sie gelernt haben, Ihre Recherche(n) entsprechend zu verfeinern. Solche Wissensdatenbanken lassen sich vor allem hervorragend zur Lehre einsetzen, vor allem dann, wenn dabei ein Netzanschluß (LAN) nicht verfügbar ist. Ein Beispiel:

Sie wollen Ihren Studenten die Anfangsgründe und Forschungsmöglichkeiten der Phonetik demonstrieren und zur Intensivierung Bild- und Tonsequenzen mitbenutzen. Sie haben aber keine Zeit, diese Lehreinheit aufwendig vorzubereiten. Hier zeigt das Internet seine wahren Stärken: aber nur, wenn Sie über geeignete Werkzeuge und Strategien eines ebenso gezielten wie effektiven Retrievals verfügen:

* Unter Windows 98 legen Sie mit dem Offline Explorer (1.2 oder höher) Ihr Projekt-URL an: hier
www.uni-koeln.de/phil-fak/phonetik.
* Das Retrieval-Projekt definieren Sie folgendermaßen:

  1. Project:
    - level limit 100;
    - skip existing files on levels higher than "0"
  2. File filters:
    - Text (all)
    - Images (gif, jpg, jpeg)
    - Video (all)
    - Audio (all)
    - Archive (zip, arj, rar, cab)
    - User defined: [add] pdf
  3. URL filters:
    - Server: load files only within the starting server
  4. Options / Advanced:
    - Internet connection: number of connections 10 (siehe unten, Hinweis 6)
    - Download directory: \www-ipk

* Nun starten Sie den Offline Explorer und kontrollieren in Abständen parallel mit dem Windows Commander, ob und wie in den Projekt-Pfad "hineingeladen" wird. Ferner achten Sie darauf, daß die Download Queue nicht zu groß wird; wenn es Ihre Zeit erlaubt, so stoppen Sie den Projekt-Download erst dann, wenn die Queue wirklich abgearbeitet ist.
* Haben Sie vergessen, einen gewünschten DL-Dateityp zu optieren, so gehen Sie auf Suspend (s.o.), tragen die Option nach und setzen dann den Download fort.
* Signalisiert OE mit "Ready", einer leeren Queue und "Speed: 0 bps", daß nichts mehr zu laden ist, so schließen Sie den Prozeß, kontrollieren mit dem Browser im Projekt-Pfad off-line alle Verbindungen (Zugänge). Ist alles OK, sichern Sie Ihr Projekt wie beschrieben auf einer CD-ROM.

      Weitere Hinweise zum Offline-Browsing und zur Projekt-Evaluation

  1. Generell können Sie Ihr Projekt offline mit beliebigen Browsern absurfen: sowohl mit dem OE-internen, ausgezeichneten Modul wie auch mit externen Programmen z.B. Netscape (ab V. 3), Opera oder dem Internet Explorer. Wollen Sie Multimedia-Dateien (mp3 u.a.) abspielen, so müssen natürlich die entsprechenden Plug-Ins oder Programme (z.B. WinAmp) implementiert sein.
  2. Der Offline Explorer selbst bietet, seinem Namen entsprechend, ausgezeichnete Möglichkeiten, das optierte Projekt entweder schon während des "Empfangs" oder off-line anzuschauen. Klicken Sie <Browse> in der Menüleiste, erscheint die Projekt-Titelseite rechts neben dem "Map"-Fenster. Sie sind damit im internen OE-Browser, der nicht nur den gewählten URL anzeigt, sondern auch verschiedene Klickfelder zum Navigieren anbietet. Wollen Sie ein bereits empfangenes Projekt (URL) ansehen, so muß unter "Options" das korrekte Laufwerk gesetzt werden (u.U. die des CD-Leselaufwerks, wenn Sie das Projekt schon entsprechend gesichert haben). Der OE-Browser arbeitet schnell, liefert eine gute Bildqualität und ist klein: das komplette Programm paßt auf eine 1,44-BM-Diskette. Das schnell startende Programm können Sie so (wie LIKSE(tm)) mit auf die jeweilige Projekt-CD kopieren und diese per Autorun selbsttätig startbar machen.
  3. 1. In jedem Pfad eines empfangenen Projekts (in mehreren URLs können tausende von Pfaden entstehen!) wird pro Directory eine Definitionsdatei *.wd3 generiert (s. Kasten unten); ihr Umfang richtet sich nach Anzahl der im Pfad angesammelten Files und kann sechstellige Byte-Werte annehmen. In nur zwei 500-kB-Projekten belegten diese *.wd3 rund 80 MB (!), in anderen Projekten waren auf 3 log. Laufwerken rund 25.000 *.wd3 (also stellvertretend für 25 k Directories!) entstanden, die innerhalb von ca. 30 Minuten etappenweise mit dem in Win 95 und Win 98 enthaltenen zentralen Find-Algorithmus aufgespürt und gelöscht werden konnten.
    2. Befinden sich mehrere umfangreiche Projekte in demselben Laufwerk, so können sich hier durchaus 5- oder gar 6stellige (!) Summen von HTML-konformen *.primary-Files angesammelt haben. Treten sie als annäherend gleichgroße Schwestern namensgleicher *.htm auf, so sind sie redundant und können auch vor Abschluß des Bulk Retrievals gelöscht werden.
    Primary-Dateien ohne *.htm-Duplikat können Sie in *. umbenennen und dann löschen.
    Browsen Sie Ihr Projekt OE-intern, so können die *.primary-Files Links auftun (und Informationen erschließen), die Ihnen sonst verloren gingen.
    Im Hilfstext zur Version 1.3 heißt es (Hervorhebungen von mir):

    [...] The purpose of .primary files is to help when updating a loaded Web site. When Offline Explorer is told not to load unmodified files, it will check every file if it was changed on the Web server or not. If not, the file is not loaded. If it is an HTML file, Offline Explorer should have its original copy with unchanged HTML links to follow them. The .primary files is the original and unmodified HTML files. Primary files are also used when existing files are not loaded. To follow links Offline Explorer takes .primary HTML files and parses them. [...]

    Descr.wd3 files reside in each directory Offline Explorer creates and contain information regarding all downloaded files in the directory:

    • file name
    • original file URL
    • date of the last modification on Web server (to check for updates)
    • file MIME type as it was returned by Web server (this is useful for offline browsing)
    • a sign, if a .primary file was created or not.

    Although all these files could be deleted, I would not recommend doing that because it may make Web site updates and offline browsing less reliable.

    3. Läßt sich die Website bis zum Abschluß (download complete) empfangen, so werden alle *.primary-Files durch das finale Parsing automatisch zum korrekten Dateinamen (in der Regel *.htm) gewandelt. Danach sind die nun überflüssigen *.wd3-Dateien zu löschen. Wird hernach der Datenträger defragmentiert, so kann das komplette Dateivolumen problemlos auf CD oder DVD gesichert werden.

  4. Werden off-line nicht alle Links korrekt "geschaltet", erhalten Sie im peripheren Zugangs-Pfad nicht den Begrüßungs-Bildschirm, sondern (u.U. verzögert) eine Anzeige aller Pfad-Dateien und müssen, um weiter zu kommen, die Datei default.htm (oder default.htm.primary) manuell anwählen. Wollen Sie das Projekt als Wissens-Datenbank aufbewahren und optimal nutzen, so müssen Sie die Surf-Autonomie in der zuständigen Leit-Datei (z.B. /redaktion/such.htm) wiederherstellen, so z.B. indem Sie Pfadangaben erweitern (aus www.???.de wird www.???.de/default.htm) oder modifizieren (HREF-Angabe für externe Server: "../ und autonome Pfade "./) oder durch das OE-Retrieval neu generierte Zugangspfade berücksichtigen (z.B. server1.uboat.net).
  5. Eine exzessive Anwendung von Mass Downloadern mit breitbandigem Empfang und statischer IP-Adresse kann den abgerufenen Host in hohem Maße belasten (viele tausend Files werden in kürzester Zeit übertragen) und besonders dann, wenn Ihre Zugriffe nicht punktuell-intermittierend ("staccato"), sondern ohne Zwischenpausen ("legato") erfolgen, als "feindlicher Akt" angesehen werden. Folglich können Ihnen (d.h. Ihrer IP-Adresse) hernach alle weiteren Zugriffe (auch einzeln per Browser!) auf den gewählten Host und sogar die gesamte Domain gesperrt werden. Daher empfiehlt es sich, solche Werkzeuge entsprechend moderat zu verwenden und folgende Parameter stark zu reduzieren:
    • Anwendungsdauer (max. 15 Minuten)
    • Zahl der parallelen Empfangskanäle (threads; max. 5-10)
    • Übertragungsgeschwindigkeit (langsamen PC und / oder langsame Netzkarte verwenden)
  6. Nach jedem umfangreichem Retrieval ist die betroffene Partition neu zu defragmentieren; befinden sich (wie Bild rechts dokumentiert) innerhalb von 2.617 MB (Clustergröße 2 KB) auf 1.853 MB nicht weniger als 159.478 Dateien in 32.945 Verzeichnissen (!), so kann dies Stunden dauern; der größte Zeitanteil entfällt auf den Schluß des Datenbalkens mit dem noch geringen Fragmentationsrest.

II. Teleport Pro (derzeit V. 1.29; Erfahrungen seit Ende Januar 2001)
Im Gegensatz zum Offline Explorer  werden bei diesem ebenfalls sehr CPU-hungrigen Programm alle Text-Dateien HTML-konform konvertiert. Zusatz- oder Hilfsdateien wie *.wd3 und *.primary (und damit entsprechende Nacharbeiten, s.o.) entfallen. Unerläßlich wird das Programm, wenn sich in einer Web-Site z.B. sehr viele HTML-konforme *.asp befinden und diese offline nicht angesprochen werden.

In max. 10 Zugangskanälen (threads) werden die angeforderten (requested) Dateien empfangen (received) und dann wahlweise in einem gemeinsamen Pfad [ohne \ivw, s.o.] oder einer der Primär-Site entsprechendem [vollständigen] Pfad-Struktur abgelegt (saved). Dann werden alle *.htm(l) automatisch gelinkt (was einige Zeit dauern kann), und die Dateien können hernach mit jedem (Frame-fähigen) Browser (kein eigener integriert!) abgesurft werden. Im Gegensatz zu OE starten Sie hier bei index.htm bzw. (seltener) home.htm; größere Projekte können zahlreiche weitere Index-Dateien (index01.htm, index02 htm usw.) erzeugen, die sekundäre URLs repräsentieren.

Ein strukturell ungünstiges Verhältnis von Primär-URL und sekundären  Sites/Links bringt nach einiger Zeit einen mit nicht genügend RAM ausgestatten Rechner zum Hängen; Sie können dann kontrolliert mit <Ctrl-Alt-Del> aussteigen und die empfangenen Dateien absurfen.

Ein  am 14.2.2001 (P II/300, 192 MB RAM) empfangenes Projekt (max. 15 primäre Sub-Pfade, max. je 3fach gestufte Sekundär-URLs erbrachte nach langem Final-Linking folgendes Ergebnis:

"Project stopped. This project has exceeded the maximum database size of 65530 URLs. Try breaking the project into smaller pieces to avoid reaching this limit. Note that the database size includes not only addresses of explored and retrieved files, but also ALL other addresses that Teleport Pro encounters while exploring the Internet. 39917 files were requested, 36117 were received, and 24971 were saved to disk."

Unter den zusammen 614,6 kB umfassenden Files befinden sich auch einige größere *.avi und *.pdf, die aus dem jeweilien File-Manager heraus mit entsprechend installierten Viewern (Windows Media Player 7, Acrobat Reader 4.05) betrachtet werden können. Das endgültig mit 24.966 Files ausgewiesene Projekt wurde anschließend mit dem Easy CD Creator de luxe 3.5c auf CD-R gesichert.

Vorteil des Single Directory Retrievals ist, daß nicht für jede externe URL ein neuer Pfad (im Root!) angelegt wird, was (wie erlebt) im Falle hunderter solcher Pfade eine spätere Löschung sehr aufwendig gestaltet; der Nachteil besteht darin, daß ein mit -zigtausenden Dateien vollgepacktes Directory von einer Sicherungs-CD nur sehr langsam auszulesen ist und daß das betroffene Laufwerk dabei über Gebühr beansprucht und verschlissen wird. Das zeigte sich, als die CD vergleichsweise mit dem Gericom Webboy (P III/800 MHz, DVD-Laufwerk) und einem Pentium I/166MMX (CD-LW 52fach, Creative) ausgelesen wurde. Im Gericom-Notebook war das Laufwerk fast ständig auf Hochtouren, vibrierte bedenklich, es dauerte lange, bis die jeweiligen Links geöffnet wurden. Das schnelle Laufwerk (Creative 52-fach) im stationären 166MMX arbeitete hingegen leise; trotz des wesentlich langsameren Prozessors kamen die Daten schneller.

Hilfreich ist, vor einer CD-Sicherung sowohl die *.htm wie auch die Bild-Dateien (*.gif, *.jpg) zu minimieren. Dies geschieht optimal mit den Dienstprogrammen HTML-Compress und Ulead Smart Server. Bei einem Projekt von ca. 520 MB lassen sich so etwa 60 bis 70 MB einsparen, außerdem - und das ist der wesentliche Vorteil - werden die Dateien schneller ausgelesen und baut sich eine aus mehreren Elementen zusammengesetzte Seite zügiger auf. Weist das Projekt 20.000 oder mehr Dateien auf, so ist eine Batch Compression sehr zeitaufwendig und beansprucht ebenso wie das anschließende Defragmentieren des Laufwerks den Rechner bis an seine Grenzen. Benutzen Sie ein Notebook mit (möglicherweise via USB gekoppeltem) externem Brenner, so sollten komplexe Projekte sicherheitshalber mit nur doppelter Geschwindigkeit geschrieben werden, da - auch bei optimal defragmentierter Platte - aufgrund eines zu langsamen BUS-Durchsatzes noch kurz vor dem Brenn-Ende ein Buffer underrun auftreten kann; Brenner mit Burn-Prooftm oder vergleichsweiser Internsoftware sind davor gefeit und eignen sich daher für die CD-Sicherung sehr umfangreicher Projekte mit 50.000 oder weit mehr Dateien in komplizierten Baumstrukturen.

Obzwar hinsichtlich der Retrieval-Optionen nicht so universell und vielseitig wie OE, ist Teleport 1.29 sehr sicher und praktikabel und eignet sich besonders für den Empfang kleiner bis mittelgroßer Web-Sites.

Wird ergänzt. Stand: 16.9.2004