Aufräumen unter GEOS & Co

Es gibt 3 Antworten in diesem Thema, welches 1.796 mal aufgerufen wurde. Der letzte Beitrag (11. Oktober 2018 um 23:34) ist von C=Mac.

  • Durch einen anderen Thread, denn ich nicht noch mehr zerschiessen will, bin ich darauf gekommen.

    Unter GEOS & Co gibt es die "Aufräumen"-Funktion (C=V).
    Dies egal ob es der original DeskTop (GEOS), TopDesk (MP3 64/128), Dashboard (Wheels 64/128) oder GeoDOS ist.

    Nun hab ich ein paar Fragen dazu: :whistling:

    1. Was macht eigentlich diese Funktion genau auf/mit der Disk/Partition/Image?

    2. Wie unterscheidet sich die "Aufräumen"-Funktion bei den verschiedenen OS/Desktops?

    3. Kann es zu Problemen führen wenn ein(e) Disk/Partition/Image mit unterschiedlichen OS/Desktops aufgeräumt wird?

    Gruss C=Mac.

    Einmal editiert, zuletzt von C=Mac (9. Oktober 2018 um 23:13) aus folgendem Grund: Tippo und Ergänzung

  • Vereinfacht gesagt: Das System sorgt dafür das die Block-Belegungstabelle (BAM) in einen zum Verzeichnis passenden/gültigen Zustand versetzt wird in dem Blöcke die durch Programme/Daten verwendet werden in der BAM als "belegt" markiert werden. Mit Hilfe der BAM kann das System dann jederzeit "freie" Blöcke finden um neue Daten aufnehmen zu können.

    Im Grunde gibt das System beim aufräumen erst einmal jeden Sektor "frei". Dann geht das System jeden Verzeichnis-Eintrag durch, ließt den Start Track/Sektor der Datei ein, markiert diesen in der BAM als "belegt", und an Hand der Sektor-Verkettung in den ersten beiden Bytes eines jeden Sektors markiert das System dann alle weiteren Blöcke als "belegt" bis das System die "Datei-Ende"-Kennung findet (Nächster Track = $00). Das gilt für sequentielle(SEQ) Dateien und Programme(PRG).
    Etwas komplizierter wird das bei Relativen-Datenbank-Dateien und den GEOS-VLIR-Dateien. Mit den REL-Dateien hab ich mich nur wenig beschäftigt, aber bei den GEOS-VLIR-Dateien ist der Dateiaufbau etwas anders.

    GEOS-VLIR-Dateien können sowohl Dokumente als auch Programme sein. Programme können dabei durch den Dateiaufbau in der Summe bis ca.8Mb groß werden (pure Theorie: 127 Datensätze x 64Kb=max.Speicher des C64). Ein "normales" Programm/PRG-Datei kann ansonsten nur so groß sein wie der max. verfügbare Speicher (64Kb).

    Bei GEOS-VLIR-Dateien liest das System aus dem Verzeichnis-Eintrag auch die beiden Bytes aus welche bei SEQ/PRG-Dateien den Beginn der Datei auf der Diskette markieren. Diese beiden Bytes zeigen auf den VLIR-Header. Der Header ist immer nur ein Block groß, hat also in den ersten beiden Bytes direkt die "Datei-Ende"-Kennung.
    Danach folgen 127 Byte-Paare die jeweils auf den Beginn eines Datensatzes zeigen können oder mit $00/FF als "nicht benutzt" bzw. $00/$00 als "VLIR-Ende" markiert sind. Wenn die Bytes auf den Beginn eines Datensatzes verweisen, dann ist der Rest wie bei einer SEQ/PRG-Datei: Durch die Sektor-Verkettung kann das System alle zum Datensatz gehörenden Sektoren finden und als "belegt" markieren. Ein Datensatz kann z.B, eine geoWrite-Dokument/Seite sein. Oder bei einem Programm eine Sub-Routine die vom Hauptprogramm nachgeladen werden kann. So lassen sich unter GEOS Programme erstellen die größer als 64Kb sind und nicht auf mehrere Einzeldateien verteilt sind.

    Das GEOS-VLIR-System ist etwas GEOS-spezifisches. Das ist etwas was eine 1541, 1581 oder eine CMD-HD von sich aus nicht kennt.
    Eine 1541 z.B. würde bei einer VLIR-Datei nur den Start-Track/Sektor=Zeiger auf VLIR-Header aus dem Verzeichnis-Eintrag einlesen und diesen als "belegt" markieren. In den ersten beiden Bytes des Sektors steht dann $00/$FF=Datei-Ende. Für das Laufwerks-System ist damit die Aufgabe beendet.

    Das erklärt dann auch warum man GEOS-Disketten mit GEOS-VLIR-Dateien (wie geoWrite-Dokuemnte oder auch geoWrite selbst) niemals mit dem VALIDATE-Befehl des Laufwerks aufräumen darf: Das Laufwerk kennt die Dateistruktur VLIR nicht und markiert nur den VLIR-Header als belegt. Für das Laufwerk ist der Header nichts anderes wie eine SEQ/PRG-Datei die nur aus einem Block besteht. Alle anderen Blöcke aus den einzelnen VLIR-Datensätzen würden durch das Laufwerk freigegeben und beim nächsten speichern von Daten ggf. überschrieben.

    Bei GEOS-Dateien gibt es dann zusätzlich noch den Info-Block der Angaben zu Autor und GEOS-Dateityp beinhaltet. Den kennt das Laufwerk selbst auch nicht und markiert diesen beim aufräumen auch nicht als "belegt".

    GEOS-Disketten müssen mit GEOS aufgeräumt (= validiert/VALIDATE = geprüft) werden, sonst droht Datenverlust. Hat man nur reine C64-BASIC-Programme oder Datendateien auf der Diskette spielt es keine Rolle ob die Diskette unter BASIC oder unter GEOS aufgeräumt wird.
    Das einzige wäre dann noch der GEOS-spezifische Border-Block des alten DESKTOP 2.0 der die Dateien vom "Rand" aufnimmt: Wenn das System als GEOS-Diskette markiert wurde ist auch der Border-Block in der BAM als belegt markiert. Den würde ein Laufwerk auch wieder freigeben.

    Das aufräumen macht z.B. dann Sinn wenn mitten beim speichern einer Datei der Strom ausfällt: Dann hat das System ggf. in der BAM bereits einige auf Disk gespeicherte Sektoren der neuen Datei als "belegt" markiert, aber noch keinen Verzeichnis-Eintrag erzeugt. Jetzt sind also auf der Disk weniger Blöcke frei als rechnerisch durch die Dateien im Verzeichnis noch "frei" wären. Das lässt sich dann durch das "Aufräumen" beheben: Da die vor dem Strom-Ausfall bereits als "belegt" markierte Blöcke keiner Datei gehören werden die beim aufräumen wieder frei gegeben.

    Ein andere Möglichkeit ist das löschen von Dateien: Löscht man eine Datei aus dem Verzeichnis wird ja nur der Dateityp im Verzeichnis auf $00 gesetzt und alle zur Datei gehörenden Blöcke durch das System wieder freigegeben. Das Laufwerk würde bei einer GEOS-VLIR-Datei auch nur den Header wieder freigeben. Sämtliche belegten Blöcke der einzelnen VLIR-Datensätze wären danach noch in der BAM als "belegt" markiert, da das Laufwerk davon nichts weiß. Diese würden aber sowohl durch das Laufwerk als auch durch GEOS beim aufräumen wieder freigegeben.

    Als letztes fällt mir noch die Dateiwiederherstellung ein: Setzt man den Dateityp einer gelöschten Datei im Verzeichnis wieder auf einen Wert <>$00, dann würde das aufräumen die zuvor durch die Datei genutzten Blöcke wieder als belegt in der BAM markieren. Auch hier kann das Laufwerk nur den VLIR-Header belegen, die Datensätze aus der VLIR-Datei selbst aber nicht. Das geht dann nur wieder unter GEOS.

    Ob das Laufwerk über VALIDATE auch die Dateigrößen im Verzeichnis-Eintrag korrigiert weiß ich derzeit nicht. Das würde aber manuelle Eingriffe in das Dateisystem erfordern. D.h. ein Programm hängt an eine existierende Datei weitere Sektoren an in dem es direkt die Sektoren auf Disk verändert und in der BAM belegt. Die Dateigröße ändert sich dadurch im Verzeichnis-Eintrag nicht automatisch.
    GeoDOS hat hier beim "aufräumen" die Option "Dateigröße korrigieren". Der Grund könnte evtl. sein das ein Laufwerk das nicht macht und das die Größe von Unterverzeichnissen nicht automatisch durch GEOS-GUIs angepasst wird wenn weitere Dateien in das Unterverzeichnis rein-kopiert werden.

    Puh... viel Text, zum Glück ist der Browser hier nicht abgestürzt! :D

  • Ob das Laufwerk über VALIDATE auch die Dateigrößen im Verzeichnis-Eintrag korrigiert weiß ich derzeit nicht.

    Nein, tut es nicht.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Bitte melde dich an, um diesen Link zu sehen.

    Besten Dank für Deine ausführliche Antwort. :thnks:


    Puh... viel Text, zum Glück ist der Browser hier nicht abgestürzt!

    Zum Glück hat Cloudflare nicht zu geschlagen. :rolleyes:

    Dann bleibt jetzt eigentlich nur noch Punkt 2 und 3.

    Gruss C=Mac.