•  Back 
  •  MagiC 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  Help page 
  •  Show info about hypertext 
  •  View a new file 
Topic       : TOS - das Betriebssystem
Author      : 
Version     : tos.hyp (5. März 2013)
Subject     : Programmieren/Atari
Nodes       : 3001
Index Size  : 93602
HCP-Version : 5
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : Titel
@help       : 
@options    : +g -i -s +x +zz -t4
@width      : 70
View Ref-File11.22  VFAT-XFS in MagiC                                           TOS

MagiCunterstützt ab Version 5.0 ein VFAT-XFS, mit dessen Hilfe sich 
lange Dateinamen im Windows95-Format auf dem Atari nutzen lassen.

Vorteile dieses Konzepts:

   ∙ bestehende Partitionen müssen nicht neu formatiert werden; die 
     langen Dateinamen stehen also direkt zur Verfügung.

   ∙ auf diese Weise erzeugte Dateien können direkt zwischen MagiC und 
     Windows95 ausgetauscht werden, und das Bearbeiten der erzeugten 
     Dateien ist auch ohne installiertes VFAT-XFS möglich (wichtig, 
     falls z.B. einmal ohne MagiC gebootet wird).

   ∙ da VFAT auf dem FAT-Konzept beruht, war eine einfache 
     Implementierung ohne nennenswerten Speicherbedarf möglich.

Nachteile dieses Konzepts:

   ∙ VFAT hat alle Probleme von FAT geerbt. So gibt es den bekannten 
     Clusterverschnitt z.B. auch unter VFAT.

   ∙ es gibt modernere Konzepte, die sowohl schneller als auch 
     sicherer sind.

   ∙ auf dem Atari fehlen derzeit noch Programme, die Volumes mit 
     langen Dateinamen reparieren können. Diese müssten allen 
     Dateinamenseinträge die unvollständig sind, oder von einem 
     falschen Haupteintrag gefolgt werden, löschen.

Technische Beschreibung des VFAT-Systems:

typedef struct
{
    BYTE   head;       /* Bit 0..4: Nummer, Bit 6: Endofname */
    UBYTE  name1[10];  /* 5 Unicode- Zeichen                 */
    BYTE   attr;       /* Attribut (0x0f)                    */
    BYTE   unused;     /* z.Zt. unbenutzt                    */
    BYTE   chksum;     /* Checksumme des kurzen Namens       */
    UBYTE  name2[12];  /* 6 Unicode- Zeichen                 */
    WORD   stcl;       /* erster Cluster (0)                 */
    UBYTE  name3[4];   /* 2 Unicode-Zeichen                  */
} LDIR;

Hinweis: Dabei ist head beim ersten Eintrag z.B. 0x01, beim zweiten 
0x02 und beim dritten 0x43, wenn der Name drei Einträge braucht.

Pro Eintrag können 13 Zeichen abgelegt werden. Die Einträge mit dem 
langen Dateinamen liegen immer unmittelbar vor dem Haupteintrag. Die 
Unicode Zeichen liegen im Intel-Format vor. Im letzten Eintrag werden 
nach dem Nullbyte die nicht verwendeten Zeichen mit 0xff,0xff belegt. 
Die Reihenfolge der Einträge ist umgekehrt, d.h. die letzten 13 
Zeichen des langen Namens liegen physikalisch an erster Stelle. Der 
letzte Verzeichniseintrag, der mit gesetztem Bit 6 im Feld head 
gekennzeichnet ist, liegt physikalisch an erster Stelle.

Die Komponente stcl ist immer Null; chksum berechnet sich aus dem 
kurzen Namen (im internen Format) durch abwechselndes Rechtsrotieren 
des bisherigen Ergebnisses und Aufaddieren der 11 Zeichen. Linux 
verwendet das Feld unused, um Flags für Groß-/Kleinschrift 
abzuspeichern. Die aktuelle Windows95-Version schreibt jedoch immer 
Nullen in dieses Feld, und so verhält sich auch MagiC. Weitere 
Hinweise:

   ∙ das Umbenennen von Dateien bei bis auf Klein-/Großschrift 
     identischem Namen ist möglich. Beispiel: Durch das Umbenennen von 
     'test.txt' in 'TEST.TXT' fällt der lange Name automatisch weg.

   ∙ die Umsetzung Unicode <-> ASCII ist entsprechend dem NVDI-Mapping 
     implementiert.

   ∙ beim Erzeugen des Kurznamens werden Leerstellen durch 
     Unterstriche ersetzt. Beispiel: 'Wassili Kandinsky.app" -> 
     "WASSILI_.APP"

   ∙ das VFAT-XFS kann (egal ob lange Namen zugelassen sind oder 
     nicht) auch Ordner innerhalb der Verzeichnisstruktur verschieben.

Querverweis: XFS-Konzept in MagiC   VFATCONF