Erstens wurde doch bereits gesagt, dass es
zwei Treiber gibt, der Fragesteller benutzt jedoch SuSE 9.1 mit einem Kernel aus der 2.6er-Reihe und da ist nun mal der neue Treiber dabei, der nicht schreiben kann und dafür performanter beim Lesen ist. Außerdem müsste dazu ein neuer Kernel gebaut werden, ich kenne den Threadersteller nicht, aber ich lese aus seinem Posting nicht heraus, dass er einen neuen Kernel bauen will.
Zweitens ist das mit der Kernel-Dokumentation so eine Sache. Du sagst, Du hast es selbst gemacht, also hast Du den alten Treiber benutzt, der dafür aber andere Nachteile hat. Ich habe in der Kernel-Dokumentation auch schon mal gelesen, dass man HPFS, das Dateisystem von OS/2, beschreiben könne, was, so leid es mir tut, schlicht und einfach nicht stimmt.
Die Kernel-Dokumentation ist nicht von überragender Qualität und enthält vereinzelt Fehler und veraltete Informationen. Wenn Du es selbst gemacht hast, dann wird es schon so sein, das muss aber nicht heißen, dass es auch mit einem SuSE-Kernel der 2.6er-Reihe funktioniert, aber um genau diesen geht es ja bei der SuSE 9.1. Ich gehe davon aus, dass einfach der Hilfetext vom alten Treiber in der Kernel-Dokumentation drin geblieben ist, weil sich niemand darum gekümmert hat, dass aufgrund des neuen Treibers die Dokumentation des alten Treibers entfernt werden muss.
Hier nochmal der Link zum Projekt, da steht doch alles:
http://linux-ntfs.sourceforge.net/status.html#ntfsdriver
Der alte Treiber kann mit dem Risiko des Datenverlusts NT4-Partitionen beschreiben, diesen hattest Du benutzt. Dieser Treiber ist out, weil sein Schreibsupport in den heutigen W2K/XP-Zeiten sowieso keinen Wert mehr hat, ich zitiere: This driver has been
completely abandoned in favour of the new one for years, auf Deutsch: Dieser Treiber ist vor Jahren zugunsten des neuen vollständig aufgegeben worden.
Drittens habe ich eine Sache gelernt, und zwar dass man weniger erfahrene Leute niemals zum Kernelbau animieren soll, weil das nur Frust produziert und von Linux abschreckt. Bei SuSE ist der neue Treiber drin, der kann, ich zitiere nochmals,
nicht schreiben: Still read-only, but with safe file overwrite support on all Windows versions without changes to the file size (uncompressed, unencrypted, nonsparse files only), auf Deutsch: Der Treiber kann immer noch nur lesen, außerdem kann er gefahrlos Dateien auf allen Windows-Versionen überschreiben, solange sich deren Größe nicht ändert.
Was müsste der Threadersteller also machen?
- Er müsste die Kernel-Quellen von SuSE holen.
- Er müsste den neuen Treiber aus den Kernel-Quellen entfernen.
- Er müsste die Kernel-Quellen mit dem alten Treiber patchen.
- Er müsste die gepatchten Kernel-Quellen konfigurieren.
- Er müsste den gepatchten Kernel übersetzen.
Und was würde der Threadersteller dafür bekommen?
- Jede Menge Fehlerquellen und Frust
- Einen Kernel, der XP-Partitionen immer noch nicht beschreiben kann, dafür aber langsamer beim Lesen ist und die XP-Partition definitiv schrotten wird, wenn man ihm vorgaukelt, die XP-Partition sei eine NT4-Partition
- Einen Kernel, der möglicherweise gar nicht gescheit funktioniert, wenn bei der Konfiguration ein Fehler unterlaufen ist
- Einen Kernel, der möglicherweise nicht einmal mehr bootet, wenn bei der Konfiguration ein Fehler unterlaufen ist
- Einen Kernel, der sich möglicherweise nicht einmal übersetzen lässt, weil der alte Treiber ja für 2.4 und nicht für 2.6 geschrieben wurde
- Einen Systemeingriff, der bei Fehlern von weniger erfahrenen Leute nicht so einfach wieder rückgängig gemacht werden kann
Wozu das Ganze? Glaubst Du ernsthaft, dass ein durchschnittlicher Anwender, und so schätze ich den Threadersteller nun mal ein, sich mit sowas beschäftigen will, obwohl es ja nicht einmal einen Sinn hat? Wenn es nichts kosten soll und nur ein paar Mal benötigt wird, dann soll der Threadersteller Captive nehmen, das ist ein fertiges RPM, das einfach installiert und hinterher wieder entfernt werden kann, die Konfiguration ist nervig, hält sich aber in Grenzen und außerdem funktioniert es. Irgendwo wird doch wohl eine ntfs.sys und eine ntoskrnl.exe von XP ohne SP2 aufzutreiben sein.
Aber ich hätte noch einen anderen Vorschlag. Vielleicht käme es ja auch in Frage, von Windows aus die Daten von der Linux-Partition zu holen. Dafür gibt es Tools, die nicht mal installiert, sondern einfach entpackt und gestartet werden.
Für ReiserFS:
http://p-nand-q.com/download/rfstool.html
Unten auf der Seite sind Links zu einfach bedienbaren grafischen Frontends sowie ein Plugin für den Total Commander. Am besten gefällt mir dieses hier, die anderen kann man natürlich auch ausprobieren:
http://yareg.akucom.de
Für ext2/ext3:
http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm
Auch dafür gibt es alternativ ein Plugin für den Total Commander und sogar einen richtigen Dateisystemtreiber, der ext2/ext3-Partitionen mit Laufwerksbuchstaben unter Windows einbindet:
http://ext2fsd.sourceforge.net
Mit diesen Tools oder besser gesagt einem dieser Tools kann der Threadersteller die Daten unter Windows von der Linux-Partition holen. Das ist, neben Captive, der Weg, den ich vorschlagen würde. Die Kernel-Geschichte ist viel zu kompliziert und lohnt sich nicht!
