PofoWiki

Die ultimative Informationsquelle zum ATARI Portfolio

Benutzer-Werkzeuge

Webseiten-Werkzeuge


hilfe:tipps:sonstiges:datenorg

Datenorganisation, -verwaltung, -ablage

Vorwort:

Tausende von Tasten drücken wir zuweilen jeden Tag, um die für uns am wichtigsten erscheinenden Daten festzuhalten. Die einen Daten sind nur kurzfristig wichtig, andere widerum müssen lange gültig sein und erhalten werden. Aus beiden Gründen speichern wir sie in Dateien ab, die der PoFo für uns in Verzeichnissen verwahrt, bis wir über den Exitus der Gültigkeit entscheiden. Dummerweise kann aber auch eine Fehlermacht den Exitus erzwingen!
Ziel dieses Workshops soll es sein, technische Hintergründe so zu vermitteln, dass man die daraus resultierenden Tipps leicht und schnell für die eigenen Daten umsetzen und verwenden kann: Zeit- und Arbeitsersparnis werden die Folgen sein!
Wenn hier von Speichermedien die Rede ist, so kann man jeden der nun folgenden Datenträger dafür einsetzen: Ramdisk, Memorycard, Memory-Modul, PCMCIA-I-Card, Disketten und Festplatten. Sie alle sind beschreib- und lesbar, was man für die Speicherung eben benötigt.

1. Thema: "Unterschiede der Speichermedien ..."

In den letzten neun Jahren wurden viele Speichermedien für den PoFo entwickelt oder bestehende Speichermedien dem PoFo angepasst. Die meisten davon benötigen eine Batterie, damit die Daten für längere Zeit gespeichert bleiben. Auch die Größe dieser Medien war und ist ein entscheidendes Kriterium zum Kauf, weil sie möglichst über den Eigenbedarf hinausgehen, also eine Reserve haben sollten.
Angefangen hat alles mit den Memorycards in den Größen 32 Kilobyte, 64 Kilobyte und 128 Kilobyte. Pardon, ich vergaß die eingebaute Ramdisk mit ihrer Standardgröße von 32 Kilobyte. Ihr Vorteil ist die fast wahlfreie Größeneinstellung in Schritten von jeweils acht Kilobyte, was ansonsten kein externes Speichermedium zu bieten hat. Weiter ging es dann sehr bald mit Memorymodulen von 256 Kilobyte bis zu einem Megabyte. Auch die PCMCIA-Karten der Klasse I, die seit kurzer Zeit per Adapter vom PoFo genutzt werden können, sind noch auf einem Megabyte Speicherkapazität beschränkt.
3,5„ Disketten mit einem Speichervolumen von bis zu 1.44 Megabyte sind eine preisgünstigere Alternative, zu den sonst sehr teuren Speicherkarten. Doch leider sind die Diskettenlaufwerke für den PoFo meist nur in geringen Stückzahlen gefertigt worden und nicht gerade billig. Weitaus häufiger und leichter zu erwerben sind Iomegas ZIP-Laufwerke, die zwar in derselben Preisklasse mitmischen wie die Diskettenlaufwerke, aber mit 100 Megabyte Speicherkapazität, pro Zip-Diskette, protzen können. Das verträgt sogar nicht mal mehr der PoFo in einem Stück, so dass Klaus Peichl einen Treiber strickte, der die 100 MB in drei verdauliche Häppchen zu 32 MB aufteilt. Der fairnesshalber seien auch hier noch die ganz seltenen Festplatten für den PoFo erwähnt, die auch in maximal 32 Megabyte-Einheiten ansprechbar sind.
Noch einmal zur Ramdisk: Sie ist ein Teil des gesamten PoFo-Arbeitsspeicher, der intern auf 512 Kilobyte oder extern auf 640 Kilobyte aufgerüstet werden kann. Auch höher aufgerüstete Ramdisks sind bekannt, aber sehr, sehr selten.
Die 3.5“ Disketten bieten den höchsten Speicher für den kleinsten Preis, sind aber auch das langsamste Medium, weil ein Diskettenlaufwerk noch mechanisch arbeitet: Der Schreib-/Lesekopf muß oft hin- und herbewegt werden, um nicht nur die Daten abzulegen, sondern um auch den Ablageort der Daten in die FAT („File Allocation Table“ = Dateibelegungstabelle) einzutragen. Diese FAT liegt, wie auch bei den anderen Speichermedien, sehr weit vorne. Auch die ZIP-Diskette ist nicht die schnellste, weil die Daten ja u.a. auch erst durch den Parallelport ins ZIP-Laufwerk gelangen, aber sie ist meiner Meinung nach noch deutlich schneller als die 3.5„ Disketten, die ich in meinem Diskettenlaufwerk namens FolioDrive verwende.
Die Speichermodule und -karten funktionieren rein elektronisch und sind unschlagbar schnell. Leider müssen sie durch Batterien die Daten am Leben erhalten, was die Verlustgefahr der Daten erhöht. Disketten, generell gesprochen, sind meist „nur“ gegen Magnetismus allergisch.
Gemeinsam ist aber allen Speichermedien die Abneigung gegen Flüssigkeiten aller Art, gegen Staub, die Angst verbogen, gefaltet oder gar gelocht zu werden, die Unverträglichkeit von Temperaturen über 60 Grad und unter 10 Grad Celsius und allzu intensive Berührung, insbesondere der Speicherfläche oder der Kontakte.
Alle Speichermedien die über die Kartenlaufwerke A: und B: am PoFo genutzt werden können, haben einen doch sehr ansehnlichen Vorteil: Von diesen Speichermedien kann das ganze System gebootet und eingerichtet werden, spezielle Dateitypen wie *.HOO- und *.RUN-Dateien sind nur auf diesen Medien lauffähig !
Spätestens wenn man die 96er Ausgabe der PCD-CD-ROM besitzt wird man feststellen, daß jedes der hier aufgezählten Speichermedien zu klein ist, denn auf besagter CD liegen 65 MB an Share- und Freeware für den PoFo bereit !

2. Thema: "So sind alleSpeichemedien aufgebaut"

Unser Betriebssystem DIP-OS ist ein Sprößling des MS-DOS, welches ursprünglich ein mit Disketten operierendes System war, daher auch der Namensteil DOS. Die Disketten sind magnetische Scheiben, welche für die Datensicherung in kreisförmige Spuren aufgeteilt wurden, damit der Schreib-/Lesekopf des Diskettenlaufwerks genau auf der Magnetscheibe positioniert werden kann.
Auch wenn Speicherkarten keinerlei Scheiben besitzen, ebenso entfällt der Schreib-/Lesekopf, haben sich die Spuren auf allen nachfolgenden Speichermedien eingebürgert, weil die Speichertechnik sich selbst bis in die heutige Zeit noch hinüber gerettet hat. So sind auch die Sektoren, die eine ganze Spur unterteilen, erhalten geblieben.
Die Sektoren sind die kleinsten Speicherplätze auf einem Speichermedium und schwanken in ihrer Anzahl, je nach Speichermedium, ganz erheblich. Irgendwo auch ganz logisch: bei 32KB benötigt man sicherlich nicht genausoviele Spuren wie bei 1.44MB und damit wird die Sektorenanzahl bei 32KB auch deutlich kleiner sein, da die Sektorenanzahl immer von der Spurenanzahl abhängig ist: x Sektoren = eine Spur. Leider kann das DOS, egal ob nun DIP-OS, MS-DOS, PC-DOS, PTS-DOS, MSX-DOS etc., nur auf eine genau begrenzte Anzahl von Sektoren direkt zugreifen. Mir ist die genaue Zahl nicht bekannt, aber das ist nun für uns auch nicht wichtig, weil man zu einem Trick greifen mußte, um alle Sektoren verwenden zu können:
Die Entwickler packten einfach mehrere Sektoren zu einem Sektor zusammen, damit die Anzahl der nutzbaren Sektoren sich erhöht. So ein Paket tauften sie Cluster, weil man zwischen Sektoren und Clustern auch unterscheiden können will. Wohl aus technischen Gründen, wie ich vermute. Auf jeden Fall hat man nun den Vorteil auch sehr große Speichermedien bearbeiten zu können, bis zu 32MB unter unserem DIP-OS nämlich. Leider hat man aber auch einen großen Nachteil: Es können nun nicht mehr Daten in einzelnen Sektoren gespeichert werden, sondern nur noch in den einzelnen Clustern, die ja wiederum eine gewisse Menge an Sektoren beinhalten: Es werden Sektoren verschwendet!
Meine Daten, die ich nun zu Speichern gedenke, würden locker in einen Sektor passen und noch etwas Platz für Änderungen lassen. Da ich aber in einen Cluster speichern muß, alle DOS-Versionen erlauben nichts anderes, werden die anderen Sektoren in dem Cluster ungenutzt bleiben, weil ein Cluster immer nur zu einer Datei gehören kann. Man kann auf jeden Fall keinen Cluster für zwei verschiedene Dateien benutzen, oder ihn auf mehrere Dateien aufteilen.
Und es kann sogar noch schlimmer kommen: Sind die zu speichernden Daten kleiner als ein Cluster, so wird der Rest des Clusters mit irgendwelchen Daten aus dem Ramspeicher aufgefüllt: So habe ich z.B. auf meiner ersten StartCard, die hatte MS mir angefertigt, Telefon-Geheimnummern gefunden, die MS wohl kurz vor der Erstellung meiner StartCard im Ramspeicher gehabt haben muß! Ich habe diese Geheimnummern aber erst durch einen Diskettenmonitor sichtbar machen können.
Die Größe eines Clusters ist von der Größe des Speichermediums abhängig und wird in Bytes gemessen. Ein Byte kann man mit einem Buchstaben vergleichen: Schreibt Ihr einen kurzen Text mit genau zehn Buchstaben im Text editor und speichert Ihr diesen als eine Datei ab, so wird die Größe der Datei auch etwa bei 10, max. bei 12 Bytes, liegen, was Ihr mit dem DIR-Befehl überprüfen könnt.
Einige gängige Clustergrößen sind, und nun wird es endlich wieder etwas konkreter: 128 Bytes, 256 Bytes, 512 Bytes und 1024 Bytes. Aber es gibt, gerade auf Festplatten, noch größere Cluster. Wieviele Bytes einen Cluster ausmachen, das ermittelt das DOS selbst, wenn es einen Datenträger formatiert und schreibt diesen Wert in den sogenannten Bootsektor des frisch formatierten Datenträgers. Dort hält es auch noch weitere Informationen fest, die es zur Benutzung des Datenträgers noch benötigt. Wir können diese weiteren Informationen jedoch jetzt vernachlässigen.
Am günstigsten für uns ist natürlich die kleinste Clustergröße von 128 Bytes, weil wir dann am wenigsten Bytes beim speichern verschenken:
Eine Datei mit 150 Bytes benötigt bei einer Clustergröße von 128 Bytes zwei Cluster und verschenkt 106 Bytes. Bei einer Clustergröße von 256 Bytes benötigt dieselbe Datei nur einen Cluster und verschenkt ebenfalls 106 Bytes. Ist ein Cluster dagegen schon 512 Bytes groß, so werden bei besagter Datei schon 362 Bytes im Cluster ungenutzt bleiben. Und nun die große Preisfrage, bei der man nur an Erfahrung gewinnen kann: Wieviele Bytes bleiben bei einer Clustergröße von 1024 Bytes übrig?
In der Praxis wird man also bei so ziemlich jeder zu speichernden Datei einige Bytes im letzten Cluster verschenken müssen, weil man, gerade bei *.COM, *.EXE und *.SYS Dateien, kaum Einfluß nehmen kann. Zum Glück ist davon auch immer nur der letzte Cluster betroffen und nicht alle!
Weil es kaum Informationen darüber gibt, welches Speichermedium welche Clustergröße hat, habe ich das mit mehreren Batchdateien in Erfahrung gebracht, die testweise Dateien und Verzeichnisse anlegten und die Änderungen per CHKDSK- Befehl in Textdateien festhielten. Zum einen war das eine MMTEST.BAT, die satte 30KB groß ist und zum anderen testete ich die Ramdisk C: mit einer etwa 9KB großen Batchdatei von Laufwerk A: aus. Sie werden sicherlich irgendwann einmal auf einer Diskette oder einer zukünftigen Club-CD-Rom zu finden sein. In mühevoller Handarbeit habe ich die aus diesen Batchdateien entstandenen Textdateien ausgewertet und in folgende Wertetabelle umgesetzt (hoffentlich fehlerfrei!):

Auswertung in Dokument zusammen gefasst: Download atari_memorycards.zip

Kommen wir zur Bedeutung dieser Wertetabelle:
Der „Speicher-Medium-Typ“ sagt uns die offiziellen Kilobytegröße des Speichermediums, manchmal auch mit seinem Namen, um eine hohe Wiedererkennung zu gewährleisten.

Ein Beispiel für die Ramdisk: Wenn bei Speicher-Medium-Typ von „8_KB“ die Rede ist, so soll das nichts anderes heißen, als das per Befehl „FDISK 8“ eine 8 Kilobyte große Ramdisk angelegt werden sollte. Die Speichergröße total leer ist in Bytes angegeben und nur dann reproduzierbar, wenn man nach der Ramdiskformatierung auch das Verzeichnis C:\SYSTEM komplett (!) löcht: DEL C:\SYSTEM, RD C:\SYSTEM.
Die „Speichergröße total leer“ soll in Bytes ausdrücken, wieviel Platz auf dem besagten Speichermedium frei ist, wenn dieses frisch formatiert wurde, und keinerlei Dateien und Verzeichnisse vorhanden sind.
Die „Clustergröße“ wird, wie oben bereits gesagt, auch immer in Bytes angegeben und sollte für uns nun keine unbekannte Größe mehr sein.
Die „max. Anzahl der Hauptverzeichniseinträge“ unterscheidet sich auch deutlich nach Größe des jeweiligen Speichermediums: Umso kleiner es selbst ist, desto kleiner muß auch die max. Anzahl sein. Hauptverzeichniseinträge können sowohl Dateieinträge als auch Verzeichniseinträge sein. Sie sind auf ein Maximum begrenzt, weil das DOS eben auch feste Werte haben muß, um alle Daten erreichen zu können.
Die „max. Einträge pro DIR-Cluster“ besagt folgendes: Unterverzeichnisse sind anders organisiert als das Hauptverzeichnis und können eine unbegrenzte Anzahl von Dateien und Verzeichnissen aufnehmen. Zumindest bis das Speichermedium voll ist.
So kann ein Verzeichnis immer weiter wachsen, weil die Dateinamen auch in Clustern gespeichert werden, die sich auf dem ganzen Speichermedium verteilen können: Merkt das DIP-OS das ein Verzeichnis wächst, so schnappt es sich zur rechten Zeit einen noch freien Cluster und kennzeichnet ihn als sogenannten DIR- Cluster, in dem dann die Namen und Cluster der noch folgenden Dateien landen werden. Der Wachstum wird also durch hinzfügen von Dateien und Verzeichnissen, in einem Unterverzeichnis, herbeigeführt. Steht in der Tabelle ein Wert von vier, so findet alle vier Einträge (unabhängig ob Datei- oder Verzeichniseinträge) ein Wachstum statt, d.h. beim 5. Eintrag wird ein neuer Cluster für die neuen Eintragungen reserviert, die dann auch gleich vorgenommen wird. Letztlich belegt also jede Datei, oder jedes Verzeichnis, doch einen gewissen Speicherplatz auf allen Speichermedien, selbst wenn z.B. eine Datei nur 0 (NULL) Byte groß ist ! Meist ist das aber so unerheblich bei den großen Speichermedien ab 1.44MB, das der verschwendete Platz wirklich belächelt wird ! Nur an uns „reichen“ PoFo-Fans hat da natürlich niemand gedacht ! Also sollte man sich reiflich überlegen, wieviele Dateien und Verzeichnisse man in einem Unterverzeichnis plaziert, weil es entsprechend viele DIR-Cluster kostet. Auch hier kann der letzte DIR-Cluster nicht vollkommen ausgenutzt sein, was man tunlichst erreichen sollte: Mehr Dateien ins Verzeichnis kopieren !
Die Eingangs erwähnten Werteabellen enthalten dazu die für Euch relevanten Informationen, anhand derer Ihr die bestmögliche Ausnutzung des betreffenden Speichermediums erreichen solltet.

3. Thema: "Verzeichnisse erstellen, wann es sich lohnt bzw. nicht lohnt"

Dies ist sehr abhängig von der Kapazität des Speichermediums. Je kleiner der Platz ist, desto mehr Verzeichnisse sollten erstellt werden. Aber auch dann muß man mit Köpfchen vorgehen, will man das beste Ergebnis herausholen ! Euch behilflich dabei sein soll wieder die obige Wertetabelle, besonders die „max.Anzahl Hauptverzeichniseinträge“.
Verzeichnisse lohnen sich:

  • wenn man mehr Dateien speichern will, als die Anzahl, die in das Hauptverzeichnis des Speichermediums speicherbar ist.
  • wenn man verschiedene Dateitypen benutzt, die man z.B. an ihren Endungen erkennt: *.TXT, *.DIR, *.WKS etc. Für jeden Typ ein eigenes Verzeichnis !
  • wenn Dateien kopiert, verschoben oder verglichen werden sollen. Immer schön von anderen Dateien trennen, damit man nicht die Übersicht verliert !
  • wenn man Dateien häufig ändert, was zur Fragmentierung führt (Dateizerstückelung). Lieber kurz ein Verzeichnis einrichten und die Datei da drin bearbeiten, als im endgültigen Verzeichnis, damit die Datei eben nicht

zerstückelt wird, was den PoFo ausbremst !

Verzeichnisse lohnen sich nicht:

  • wenn man weniger Dateien zu speichern hat, als die Anzahl, die in das Hauptverzeichnis des Speichermediums speicherbar ist.
  • wenn man wirklich nur einen Dateityp speichert, oder nur die Dateien einer Tagesarbeit sichern muß.
  • wenn nur ein Datentyp kopiert, verschoben oder verglichen werden soll.
  • wenn Dateien absolut nicht verändert werden.

Meistens lohnen sich die Verzeichnisse immer, aber man sollte schon ein wenig vorher Nachdenken was dabei abgeht wen man solche einrichtet, denn es bedeutet immer einen gewisse Speicherverlust oder -verschwendung: Jedes Unterverzeichnis bekommt zunächst einen DIR-Cluster und wächst dann, durch weitere Einträge, um weitere DIR-Cluster an !

Aufgabenstellung:

Weil die Anzahl der möglichen Datei- und Directoryeintragungen, im jeweiligen Hauptverzeichnis eines Speichermediums, sehr klein sein kann, lohnt es sich das Hauptverzeichnis nur für die Startdateien CONFIG.SYS, AUTOEXEC.BAT und für möglichst viele Unterverzeichnisse freizuhalten. Darum sollten alle Dateien, außer den eben genannten Startdateien, in ein Unterverzeichnis names \SAV verschoben werden. Dieses verschieben sollte nach jedem Warm- oder Kaltstart vollautomatisch geschehen.
Wie lauten dazu die entsprechenden Batchzeilen, wenn eine Speicherkarte in A: vorhanden wäre und wie heißt die Batchdatei, die das erledigen muß ?

  1. TIP: Verschieben erreicht man durch COPY und DEL.
  2. TIP: Die Startdateien müssen kurzfristig mitkopiert werden.
  3. TIP: Die A:\AUTOEXEC.BAT darf dabei nicht gelöscht werden.
  4. TIP: Für das löschen muß man die Befehle FOR, IF, NOT und DEL kombinieren.

Lösung:

MD A:\SAV
COPY A:\* . * A:\SAV
FOR %%A in (A:\SAV\* . *) DO IF NOT % %A = = AUTOEXEC.BAT DEL %%A
COPY A:\SAV\CONFIG.SYS A:\
DEL A:\SAV\AUTOEXEC.BAT
DEL A:\SAV\CONFIG.SYS 

7. Thema: "Der PoFo bleibt ein Rennpferd, trotz vieler Dateien"

Die häufige Änderung bestehender Dateien bringt, gerade wenn die Dateien mit jeder Änderung größer und größer werden, einen Geschwindigkeitsverlust mit sich, weil der PoFo die Datei nicht in einem Stück speichern kann. Schließlich liegt vor der zu ändernden Datei eine andere und genau hinter ihr meist wieder eine andere. Beim speichern der Ergänzung muß daher ein neuer Platz für diese gesucht werden, der dann meist hinter der letzten Datei zu finden ist. Leider kann das DIP-OS, auch Microsofts Betriebssystem können das bisher nicht, nicht die nachfolgenden Dateien verschieben, um die Datei inklusive der Ergänzung zu speichern.
Im Fachjargon werden diese Ergänzung als Fragmente (Teile) bezeichnet und die verteilte Speicherung dementsprechend Fragmentierung geschimpft. Sie ist deshalb so unbeliebt, weil das Betriebssystem beim Laden und beim Speichern auf die Suche nach den Fragmenten gehen muß, was entsprechend Zeit benötigt. Sehr stark macht sich das auf mechanischen Laufwerken bemerkbar: Man hört regelrecht wie der Schreib-/Lese-Kopf auf der Diskettenoberfläche hin- und herfährt. Bei den Speicherkarten, die verdammt schnell sind, ist der Zeitverlust trotz kleiner MHz-Zahl des PoFo, nicht so stark zu bemerken. Trotzdem wird das mit jeder Änderung den PoFo verlangsamen, wenn er auf die Dateien zugreift.
Es lohnt sich daher von Zeit zu Zeit eine Defragmentierung durchzuführen, die man auf dem PoFo so per Hand vornimmt: Möglichst auf einem anderen Speichermedium richtet man ein Verzeichnis ein und kopiert alle Dateien aus dem gerade aktuellen Unterverzeichnis in das neue hinein. Dann löscht man alle Dateien im aktuellen Unterverzeichnis. Jetzt wechselt man mit „CD..“ ein Verzeichnis höher und entfernt das eben noch aktuelle Unterverzeichnis mit dem RD-Befehl. Gleich darauf legt man das Unterverzeichnis mitels MD-Befehl wieder an und kopiert die zwischengelagerten Dateien wieder hinein. Das Verzeichnis, in dem die Dateien kurzfristig zwischengelagert wurden, sollte inklusive der Dateien dann wieder gelöscht werden. Hat man kein anderes Speichermedium, so sollte das Verzeichnis für die Zwischenlagerung im Hauptverzeichnis erstellt werden.
Im ersten Moment erscheint es widersinnig zu sein, daß Verzeichnis zu löschen und im nächsten Moment dasselbe Verzeichnis wieder anzulegen, aber das hat doch einen Grund:
Viele Dateien in einem Verzeichnis benötigen auch viele DIR-Cluster. Werden aber viele Dateien gelöscht, so werden die DIR-Cluster nicht automatisch zur Speicherung wieder freigegeben ! Sie sind erst dann wieder verfügbar, wenn man das Verzeichnis löscht. Und weil man sich sicherlich nicht permanent dran erinnern kann wieviele Dateien maximal jemals in einem Verzeichnis waren, sollte man generell das Verzeichnis im Zuge der Defragmentierung mal kurz mitlöschen ! Hier mal ein Beispiel für manuelle Defragmentierung auf dem PoFo:
Verzeichnis C:\TEST soll defragmentiert werden unter Benutzung einer MMC in A:, die noch genug Platz hat.

Auslagerungsverzeichnis erstellen:

  • md a:\defrag
    • Dateien von C:\TEST
    • nach A:\DEFRAG kopieren:
  • copy c:\test a:\defrag
    • Dateien in C:\TEST löschen:
  • for %a in (c:\test\* . *) do del c:\test\% a
    • C:\TEST entfernen um
    • verschwendete DIR-Cluster wieder
    • nutzbar zu machen:
  • rd c:\test
  • C:\TEST wieder anlegen: md c:\test
    • Genaue Anzahl DIR-Cluster in sortierter
    • Reihenfolge anlegen:
  • for %a in (a:\defrag\* . *) do rem>c:\test\%a
    • Dateien von A:\DEFRAG wieder nach
  • C:\TEST kopieren:
  • for %a in (a:\defrag\* . *) do copy a:\defrag\%a c:\test
    • Defragmentierung ist nun abgeschlossen !
    • Jetzt wird A:\DEFRAG wieder gelöscht, zunächst die Dateien:
  • for %a in (a:\defrag\* . *) do del a:\defrag\%a
    • Und nun wird A:\DEFRAG gelöscht:
  • rd a:\defrag
    • endgültiges Ende !

Das ganze nocheinmal als automatisch ablaufende Batchdatei:

  @echo off
  md a:\defrag
  copy c:\test a:\defrag
  for % %a in (c:\test\*.*) do del c:\test\% %a
  rd c:\test
  md c:\test
  for % %a in (a:\defrag\*.*) do rem>c:\test\% %a
  for % %a in (a:\defrag\*.*) do copy a:\defrag\% %a c:\test
  for % %a in (a:\defrag\*.*) do del a:\defrag\% %a
  rd a:\defrag

Und zu guter letzt als flexible DEFRAG.BAT:

  @echo off
  md a:\defrag
  copy %1 a:\defrag
  for % %a in (%1\*.*) do del %1\%%a
  rd %1
  md %1
  for % %a in (a:\defrag\*.*) do rem>%1\% %a
  for % %a in (a:\defrag\*.*) do copy a:\defrag\%% a %1
  for % %a in (a:\defrag\*.*) do del a:\defrag\% %a
  rd a:\defrag

die mit „DEFRAG Verzeichnis“ zu starten ist. Baut man noch ausreichende Fehlerbehandlung mit ein, oder gar die Verwendung des externen XCOPY Programmes, so kann man tatsächlich ein DEFRAG Programm für den PoFo kreieren.

Schlußwort

Jeder von uns hat sein ganz eigenes Ordnungssystem und dementsprechend klare Vorstellungen darüber. Darum sind die hier gezeigten Tips als Anregungen für eigene Überlegungen zu verstehen und zu gebrauchen.

Viel Spaß dabei wünscht Euch:
Lars Aschenbach

hilfe/tipps/sonstiges/datenorg.txt · Zuletzt geändert: 07/04/2007 00:04 (Externe Bearbeitung)