RISC OS macht bekanntlich vieles anders als andere Betriebssysteme. Besonders augenfällig ist das im Bereich Dateisysteme, was regelmäßig für Verwirrung sorgt. Dieser Artikel soll helfen, den Überblick zu bewahren.
Beteiligt am bunten Filesystem-Treiben unter RISC OS sind beispielsweise folgende Kandidaten:
- Fileswitch
- Filecore
- SCSIFS, ADFS, SDFS, IDEFS…
- CDFS, CDROMFS
- DOSFS, Fat32FS, Win95FS
- SparkFS, TBAFS, X-Files…
- Sunfish, ImageNFS, NFSClient, LanManFS, LanMan98…
- HostFS
- PipeFS
Vorabinfo: Image-Filing-Systeme
Eine Besonderheit von RISC OS ist die Unterstützung von Image-Filing-Systemen. Darunter versteht man die Möglichkeit, eine einzelne Datei (oder auch ein ganzes Medium wie eine Festplatte, ein USB-Stick oder eine Diskette) als Verzeichnis zu behandeln. Bekannte Implementierungen sind z.B. DOSFS (Zugriff auf FAT-Medien) oder SparkFS (Zugriff auf Archive wie ARC, ZIP und ARJ). Für viele Operationen sind solche Images nicht von normalen Verzeichnissen zu unterscheiden – von der Kommandozeile aus z.B. kann problemlos in den Innereien einer ZIP-Datei herumgefuhrwerkt werden, wenn SparkFS aktiv ist. Alles funktioniert völlig transparent. Nur auf SWI-Ebene kann man herausfinden, ob ein Objekt ein “File” ist, ein “Directory” oder ein “Image” – wobei das “Image” auf dieser Ebene dann entweder als File oder als Directory bearbeitet werden kann.
Die Basis: Fileswitch
Basis aller Dateisystem-Dinge ist Fileswitch. Hier registrieren sich alle tatsächlichen Dateisysteme (egal ob “echte” oder “Image-Filing-Systeme” mit ihren “Entry points”). Hier sind die SWIs definiert, die in RISC OS die Schnittstelle zum Dateisystem bilden, von OS_Args über OS_File bis OS_GBPB.
Fileswitch definiert die “special characters” von RISC OS-Dateisystemen wie “$”, “:”, “&” und “%” und die Wildcards “*” und “%”, legt fest dass der Verzeichnistrenner “.” ist und beschäftigt sich mit den berühmten 8 Bytes, die entweder 5 Byte Datestamp + 12 Bit Filetype repräsentieren oder 4 Byte Load address + 4 Byte Exec address. Dazu gibt es noch ein volles Word Attribute.
Fileswitch ist ansonsten weitestgehend agnostisch gegenüber Implementierungsdetails. Zeichensatz? Physikalische Abbildung der logischen Verzeichnisstruktur auf dem Datenträger? Maximale Länge eines Dateinamens? All das bestimmt die Implementierung des Fileswitch-Clients. Die API ist leider nur 32bittig, d.h. die maximale Dateigröße ist auf 4 GiB begrenzt (lange Zeit (vor RISC OS 5.22) konnte Filecore sogar nur 2 GiB-Dateien verwalten). Wichtig zu wissen: Fileswitch ist inhärent case-insensitiv.
An dieser Stelle sollte aber beachtet werden, dass zwar Fileswitch gegenüber vielen Details agnostisch ist, aber leider nicht jede Software, die Fileswitch verwendet. Denn die meisten Entwickler testen ja mit real existierenden Dateisystemen, und oft nur mit einem – Filecore. Wenn sich dann andere Dateisysteme zwar API-konform, aber nicht gleich wie Filecore verhalten, führt das oft zu Verdruss. Beispiele in der Vergangenheit waren das Enumerationsverhalten von Verzeichnissinhalten bei Fat32FS, HostFS oder Sunfish.
Übrigens ist das Dateigrößenlimit von 4 GiB ein größeres Problem, als es zunächst scheint. Denn es limitiert nicht nur (logischerweise) die Größe einer Datei, sondern auch die Größe des Mediums, das ein Image-Filing-System verwalten kann. Deshalb ist DOSFS nicht in der Lage, mit FAT-formatierten USB-Sticks umzugehen und man benötigt Fat32FS, das als “echtes” Dateisystem implementiert ist und daher nicht an das 4 GiB-Limit der Image-Filing-Systeme gebunden ist.
Das native Dateisystem: Filecore
Filecore hat eine lange Historie bis zurück in die Zeit der 8-Bitter. Von Anbeginn der RISC OS-Zeit war das “Filecore E”-Format das native Dateisystem auf Disketten und Festplatten. Lange Zeit (bis RISC OS 4) ein Ärgernis, da limitiert auf maximal 10 Zeichen pro Dateiname und 77 Objekte in einem Verzeichnis. Aber ziemlich clever, was die Platzausnutzung des Mediums angeht (über “shared fragments” erreicht man eine feinere Granularität als die Blockgröße) und die Optimierung mit automatischer Defragmentierung.
Verschiedene RISC OS-Versionen haben unterschiedliche Limitierungen bezüglich Filecore. Alles bis einschließlich RISC OS 3.5 hatte eine maximale Partitionsgröße von 512 MiB (nicht zu verwechseln mit dem alten BIOS-PC-Limit von 504 MiB), alles bis einschließlich RISC OS 3.7x konnte nur 10 Zeichen pro Dateiname und 77 Objekte pro Verzeichnis.
Aktuelle Limits bei RISC OS 5 sind 256 GiB pro Partition bei einer Blockgröße von 512 Bytes. Theoretisch kann Filecore auch andere Blockgrößen (traditionell 1024 Bytes, inzwischen auch 2048 und 4096 Bytes), aber das wird meines Wissens derzeit von keinem Filecore-Client unterstützt.
Jede Filecore-Instanz kann maximal 8 Geräte verwalten, 4 Festplatten und 4 Wechselmedienlaufwerke. In der Theorie wurde das RISC OS 5-Filecore durch einen neuen Aufruf erweitert, um theoretisch bis zu 256 Geräte mit jeweils bis zu 16 EiB (also 16 Milliarden GiB) zu verwalten. Meines Wissens ist das aber nicht ausimplementiert. Insbesondere größere Medien wären schlecht zu handhaben, weil die Größe der Filecore-Map linear mit der Größe des Mediums wächst und vollständig im Hauptspeicher liegen muss.
Geht bei Filecore etwas schief, sind die Bordmittel um etwas zu retten sehr begrenzt. Der *CheckMap-Befehl kann zwar die Map auf Konsistenz prüfen, aber wenn sie inkonsistent ist, gibt es keine Lösungsmöglichkeit. *Verify prüft im Prinzip nur, ob die einzelnen Sektoren bzw. Blocks lesbar sind. Man muss kaputte Sektoren dann von Hand per *Defect als kaputt markieren.
Deshalb sollte jeder RISC OS-Benutzer auf jeden Fall DiscKnight von David J. Ruck in seiner Werkzeugkiste haben. Und zwar auf jedem Medium – besonders auf Netzwerkmedien, auf die man auch im Falle des Falles zugreifen kann, wenn die Platte oder der USB-Stick nicht mehr wollen. Schmale 10 UKP sollte das jedem wert sein.
Besondere Vorsicht ist auch beim Löschen geboten. Es gibt hier keinen (sicheren) Weg zurück, schon der nächste Schreibvorgang kann die soeben gelöschten Daten unwiederbringlich überschreiben. DiscKnight hat deshalb ein Feature, den freien Speicherplatz einer Filecore-Partition in eine Datei zu verwandeln, so kann man ggf. gelöschte Daten wiederherstellen.
Die Brücke zur Hardware: ADFS, SCSIFS, SDFS, IDEFS
Jeder RISC OS-Nutzer kennt ADFS. Ursprünglich (RISC OS 2, Archimedes, als Festplatten noch unsäglich teuer waren) als ADFS::0 der Zugang zum einzigen Diskettenlaufwerk, wird es später um ST506-basierte Festplatten (MFM) und noch später um IDE-basierte Festplatten erweitert. Eines blieb immer gleich: ADFS unterstützt nur eine Partition. Von Drittherstellern gibt es BDFS und EADFS mit Multi-Partition-Support.
ADFS ist, genau wie SCSIFS, SDFS und IDEFS, ein Filecore-Client. In anderen Worten: ADFS kümmert sich darum, Zugriffsroutinen bereitzustellen, um Blöcke von Geräten zu lesen und auf sie zu schreiben. Das logische Dateisystemformat steuert also Filecore, den Zugriff auf die physischen Geräte ADFS.
Selbiges gilt für SCSIFS, das aber nicht nur für die weitestgehend ausgestorbenen SCSI-Geräte zuständig ist, sondern auch für USB-Geräte vom Typ “Mass Storage” – dazu wird über SCSISoftUSB ein Low-Level-Treiber in den SCSIDriver integriert, der USB-Geräte als SCSI-Devices bereitstellt, damit SCSIFS darauf zugreifen kann.
SDFS und IDEFS schlagen in dieselbe Kerbe, nur eben für Zugriff auf SD-Karten und IDE-Geräte, wobei IDEFS von Drittherstellern von IDE-Podules bereitgestellt wurde und meistens mehrere Partitionen unterstützt.
Durch die Konstruktion “xxFS ist das Dateisystem das ein Filecore-Client ist, Filecore ist ein Fileswitch-Client, aber der eigentliche Hardware-Treiber sitzt wieder in xxFS” wurde der Filesystem-Stack von RISC OS oft als “upside-down” charakterisiert.
Scheibenversteher: CDFS, CDROMFS
Mit CDFS und CDROMFS verlassen wir die Welt der Filecore-Clients und nehmen die ersten Dateisysteme, die direkt an Fileswitch andocken, unter die Lupe.
CDFS war anfangs eine “SCSI-only”-Veranstaltung und konzentrierte sich ganz auf das ISO9660-Format, dem Standard für Daten-CDs. Mitte der 90er, als CDROM-Laufwerke langsam gebräuchlich wurden, führte CDFS die Technik des “softloadable drivers” ein – man konnte nun Module bauen (typische Namen: CDFSSoftSCSI2, CDFSSoftATAPI), die die Verbindung zur Hardware übernahmen. Praktisch jeder Anbieter von SCSI- und IDE-Podules hatte seinen eigenen Treiber, dazu kamen generische Treiber von EESOX und IOC (später Pulse Computer) für SCSI sowie Power-tec und EESOX für ATAPI.
CDROMFS von Warm Silence Software (geschrieben von Ian Fry) ist ein Ersatz für CDFS. Und zwar nur für das CDFS-Modul, CDROMFS benutzt die Treiberinfrastruktur von CDFS einfach weiter. CDROMFS versteht mehr Varianten von ISO9660, versteht Joliet und Teile von RockRidge sowie ein Subset von UDF. Außerdem ist CDROMFS ein Image-Filing-System, kann also ISO-Images direkt öffnen – CDFS kann das nur in Verbindung mit CDFaker.
CDFS wurde inzwischen auch weiterentwickelt und versteht seit RISC OS Select und RISC OS 5.20 ebenfalls Joliet.
Ausblick
Im nächsten Teil geht es um die “FAT-Versteher” DOSFS, Fat32FS und Win95FS. Um ein paar interessante Image-Filing-Systeme wie DOSFS, Win95FS, SparkFS, TBAFS und X-Files. Um Netzwerk-Clients wie Sunfish, ImageNFS, NFSClient, LanManFS und LanMan98. Dazu ein kurzer Blick auf HostFS, dem Dateisystem der Emulatoren. Und eventuell PipeFS, das u.a. für den Zugriff auf USB genutzt werden kann.
Ein weiterer zukünftiger Artikel soll skizzieren, was im Bereich Dateisysteme in RISC OS geändert werden sollte. Bei RISC OS Open Ltd. gibt es ein offenes “Filesystem bounty”, das sich mit der Problematik der Partitionierung beschäftigt. Ein erster Schritt ist bereits getan. Die gesamte Roadmap ist hier und hier skizziert.