So, Leute!
Habe mir nochmal einen weiteren Satz Hörner abgestoßen. Wollte das Problem (zumindest einen Teil davon) ganz einfach über Shell-Programme lösen und versuchte daher,
inodes zu verwenden. Ich komme auch per
an diese Info, aber auf der Scheibe kann ich dann mit den ausgegebenen inode-Nummern 1410, 1412 usw. nichts anfangen. Da ich keinen Diskmonitor habe, las ich einfach einen Schwung Sektoren per
Code: Alles auswählen
dd if=/dev/sr0 of=/home/domino/temp3.raw bs=2K skip=0 count=1024
auf die Platte ein und konnte dann mittels GHex (einem Datei-Hexmonitor) nachsehen. Ab Position 1410*32→$b040 gibt’s zwar die zweite Auflistung des Inhaltsverzeichnisses der DVD (in vermutlich UTF-16, die erste ist in ASCII und für ISO9660) und darin finde ich auch meine gewünschte Info als Sektornummer (sogar in Little Endian und Big Endian!), aber die Datenstrukturen passen in der Länge nicht zu den
inodes 1412, 1415 usw.. Übrigens stimmen diese Nummern nur für Daten-DVDs. Bei VideoDVDs (mit den bekannten Verzeichnissen AUDIO_TS und VIDEO_TS) erhalte ich
inodes ab 266, die Daten auf der Scheibe sind aber ab ungefähr $80000 zu finden. Also:
inodes sind eine Sackgasse.
Muß ich denn wirklich ein ISO-Dateisystem in mein Progrämmchen einbauen, nur um die Startposition einer Datei auf der Scheibe zu erhalten? Stichwort: Kanonen und Spatzen.
Weiteres Verständnisproblem: Wenn ich nicht dateiweise, sondern partitionsweise lesen will (unter GNU/Linux ist alles eine Datei), komme ich mit
nicht weiter. Geöffnet wird zwar, aber die Dateilänge beträgt nur 20 Bytes! Will ich diese mit ReadData() auslesen, werden 0 Bytes zurückgegeben. Mit /dev/sr0 hab ich es noch nicht probiert, da es sich nur um eine 0-Byte-Datei handelt. Weiß da jemand, wo’s bei mir klemmt?
Da muß man Stunden und Tage verdaddeln, nur um an Infos zu kommen, die man gleich mit einer Funktion FileStat() erhalten können sollte. Klar hat man normalerweise mit Festplatten zu tun, auf denen immer mit Datenfragmentierung zu rechnen ist und man deshalb nie von einer linearen Anordnung der Sektoren ausgehen darf. Da ist die Angabe der Sektornummer des ersten Datenblocks sinnbefreit. Da dem Brennen von CDs, DVDs und BDs aber immer die vollständige Erstellung eines Abbildes vorausgeht, kann und wird man immer dafür sorgen, daß es keine Fragmentierung gibt. Hier ist die Angabe des ersten Datenblocks sehr wohl sinnvoll!
Per FileStat() sollten Startposition, Länge in Bytes und in Sektoren, die Sektorgröße, Erstellungs-, Änderungs- und Zugriffsdatum usw. zurückgegeben werden. Für letztere Angaben gibt es die Funktion GetFileDate(), aber für die für mich wichtigen Daten eben keine.
@GPI: Null Problemo! Startsektor der Datei auf der Scheibe mal Sektorgröße plus Absolutposition in Datei gleich Position auf der Scheibe. Mit der Info des Maximalvolumens in Bytes (z.B. 4483MB) und des Innen- und Außendurchmessers des beschreibbaren Bereichs komme ich schnell zum Radius. Der Winkel der Drehachse ist völlig unerheblich. Dann suche ich mir die verkratzte Stelle mit diesem Radius heraus und poliere, bis ich die Stelle lesen kann. Abschließend, wenn alle Daten lesbar sind, wird die ganze Scheibe nochmals auf Hochglanz gebracht oder von den gesicherten Daten gleich eine neue Scheibe gebrannt.
Gruß – Domino