Datentypen Floppy-Image-Dateisystem

[FlexPortable]

Kennt Java das Floppy-Image-Dateisystem?

Ich möchte mir gerne eine kleine GUI-Applikation erstellen, mit der ich Ordner und Dateien eines gewünschten Ordner als Floppy-Image abspeichern kann.

Wenn nicht weiß jemand, wie das Floppy-Images-Dateisystem aufgebaut ist? Wenn es nicht allzu sehr kompliziert und notwendige Algorithmen im Internet findbar sind bzw. es gar keine allzu schwer notwendige Algorithmen notwendig sind oder gar nicht, könnte ich mir auch vorstellen, selbst einen Byte-Formatierer zu schreiben.

 

[Spacerat]

Äehm... Floppy-Image-Dateisystem... welches? CBM1540/41, CBM1570/71, HDFFS, FFS, OFS, Atari-Dos? Es gibt so viele... verdammt viele Ey... sorry, dass ich PC-Dos vergessen hab' aber des kennen doch eh' alle...

So, aber um die Frage zu beantworten; Java kann solche Dateien natürlich lesen, aber es kann von Haus nichts damit anfangen. Wenn man weis um was für ein Image es sich handelt, ist es ein einfaches, in Java einen Reader dafür zu schreiben.

 

[FlexPortable]

Also laut einem Linux-Artikel meine ich MS-DOS formatiertes mit FAT12, dass in Linux als msdos Typ verwendet wird.
Nur weiß ich echt nicht wie diese Formatierung aussieht. Hat die auch ein Index, oder werden da die Dateien einfach Bit für Bit, in die neue Datei (Imagedatei), aneinander gehängt kopiert? Wie ist der Code (Bits) für eine Trennung (zwischen Ende der vorangegangen Datei und Anfang der folgenden Datei)? Wie werden die Ordner abgespeichert (die ja gewissermaßen den Ort der einzelnen Dateien regelt)? Mittels Index?

Oder gibt es da schon eine Methode in Java?

 

[Spacerat]

Nö... eine Methode gibt es dafür sicher nicht. Das Problem ist, dass man sich erst mal mit dem von der Hardware vorgegebenen Strukturen (Köpfe, Spuren, Sektoren und Anzahl der Bytes pro Sektor) auseinander setzen muss und dann erst mit dem eigentlichen Dateisystem. Für ein PC-HD-Laufwerk ergeben sich daraus schon mal die Werte 2, 80, 18 und 512 -> 1,44Mb. Mit diesen Daten ist es nun schon mal ein Leichtes, so ein PC-HD-Image blockweise zu indizieren. Wenn man nun noch weis, wie die Daten dann z.B. bei Fat12 darauf organisiert sind, ist der Reader dafür schon so gut wie fertig. Wenn man nun noch Hardware vom Dateisystem im Sinne der OOP für Wiederverwendbarkeit trennt, schreibt sich ein weiterer Reader für z.B. Minix noch um einiges leichter.

 

[FlexPortable]

Also dann kennt Java doch nicht dieser Art der Formatierung? Ich betone das es sich um Imageerstellung handelt, also eine Datei und nicht das ansprechen von Hardware, außer vielleicht das Lesen und Schreiben um die Datei dann zu erstellen, aber dabei greift man ja nur auf Funktionen zurück die schon in Java definiert sind.

Mehr oder Weniger hängt es also vom Programm ab, dass mittels der Image-Datei die Daten auf eine reale Floppy schreibt, wie das Image auszusehen hat (formatlich, nicht inhaltlich). Es gibt aber wohl schon lange ein inoffizielles Standart wie so ein Floppy-Image auszusehen hat.

Bei Linux gibt man den Befehl 'dd if=/dev/zero of=1_Floppy1440.img bs=1024 count=1440' um ein Floppy-Image anzulegen, was für eine 1,44MB große Floppy sein soll. Und damit es dann FAT12 formatiert ist, gibt man zusätzlich den Befehel 'mkdosfs -F 12 1_Floppy1440.img'.
An sich sind die Parameter leicht zu interpretieren wo bei ich gerade nicht weiß ob es 1440 x 0 oder 1440 x 255 sind.
http://www.jay-code.de/files/fat12.pdf

Wenn ich mich nicht täusche, dürfte also eigentlich FAT12 die einzige zu beachtende Regel sein und in diese Formatierung nach den FAT12 Vorgaben fügt man dann die Ordner und Dateien ein.

 

[Spacerat]

Also dann kennt Java doch nicht dieser Art der Formatierung? Ich betone das es sich um Imageerstellung handelt, also eine Datei und nicht das ansprechen von Hardware, außer vielleicht das Lesen und Schreiben um die Datei dann zu erstellen, aber dabei greift man ja nur auf Funktionen zurück die schon in Java definiert sind.

Also das es nicht direkt um das Ansprechen der Hardware geht, war schon von vorne herein klar. Aber wie könnte so ein Image denn sinnvoller aufgebaut sein, wenn es kein Abbild dieser Kunststoffscheibe (Hardware) liefert. Sinnvoll wäre doch eine Einteilung in ein 4-Dimensionales Bytearray:

public abstract class HDDiskImage
{
  public static final int HEADS = 2;
  public static final int TRACKS = 80;
  public static final int SECTORS = 18;
  public static final int BYTES_PER_SECTOR = 512;
  public static final int IMAGESIZE = HEADS*TRACKS*SECTORS*BYTES_PER_TRACK;

  private final byte[][][][] data = new byte[TRACKS][SECTORS][HEADS][BYTES_PER_TRACK];

  protected HDDiskImage(File image)
  throws IOException
  {
    if(image.length() != IMAGESIZE) {
      throw new IOException("invalid image size");
    }
    FileInputStream fis = new FileInputStream(image);
    for(int t = 0; t < TRACKS; t++) {
      for(int s = 0; s < SECTORS; s++) {
        for(int h = 0; h < HEADS; h++) {
          fis.read(data[t][s][h]);
        }
      }
    }
  }

  // Code zum interpretieren des Images.

  /**
   * z.B. readSector()
  **/
  public final byte[] readSector(int track, int sector, int head)
  {
    // Abfragen zur Konsistenz der Parameter fielen der Faulheit zum Opfer ;)
    return data[track][sector][head].clone();
  }

  // Abstrakte Methoden für verschiedene Dateisysteme

  /**
   * z.B. dir
  **/
  public abstract List<String> dir();
}

So viel erst mal zur Vorgehensweise bei der Interpretation der Images. Das Dateisystem ist Sache einer konkreten Klasse. Der Code oben ist jetzt aber nur relativ dahingepfuscht, um zu zeigen, wie es geht. Eleganter als ein 4-Dimensionales Array bleibt natürlich ein (Direct)ByteBuffer unt die Positionierung auf einen Sektor findet dann über eine aus Track, Sector und Head errechnete Adresse statt.
Wenn man will, kann man die Anzahl der Köpfe auch weglassen, wie in Linux z.B. und die Sectorgrösse auf 1024 Bytes vergrössern. Allerdings müsste man dann nur noch mit einem Offset (512) an die Daten des 2. Kopfes.