[Sturmovik]

Hm, zusammengefasst für mein verständnis: ntfs-partition in Debian gemounted und dank Absturz beim Schreiben den MFT frittiert... Eigentlich sollte hier das journalling dafür sorgen, dass das filesystem wieder in einen konsistenten Zustand gebracht werden kann.

GParted kann das nicht, will und soll es auch nicht können. Das ist ein Partitionierungswerkzeug, kein FS-Recoverytool.
Für sowas gibts unter Unixoiden schon immer fsck, in deinem Fall fsck.ntfs

Was du unter Linux auch versuchen könntest, wäre testdisk. Ist glaubich auch im Debian-Repository

Ansonsten Windows mal einen Konsistenzcheck machen lassen. Das sollte Windows schon beim Boot machen, weil es nicht in der Lage ist, die unsaubere Partition zu mounten.

---

Edit: fsck.ntfs macht nur diagnose und versucht sich vernünftigerweise nicht am fixen eines defekten MFT. Außerdem scheints in Debian aktuell gar nicht enthalten zu sein. _Dafür gibts ntfsfix.

Ich würde allerdings hier eher auf Windows vertrauen, kein Betriebssystem kommt besser mit NTFS klar als NT selbst. Und um deine ext4-Partitionen musst du dir keine Sorgen machen, die lässt Windows in Ruhe, da es mit ext* nix anfangen kann (außer wenn du mit diskpart oder der DT-Verwaltung rumspielst)

Dieser Beitrag wurde von Sturmovik bearbeitet: 25. August 2016 - 16:04

[expat]

Zitat (Sturmovik: 25. August 2016 - 15:26)

GParted kann das nicht, will und soll es auch nicht können. Das ist ein Partitionierungswerkzeug, kein FS-Recoverytool.

GParted kann auch (ausgehängte) NTFS-Partitionen überprüfen.

Wenn windows nicht von diesen "verschwundenen" Parttionen betroffen ist , dann kann man ruhig dahin booten.
Chkdsk /f geht so. Bei der Suche cmd.exe eingeben. Mit klicken darauf mit rechter Maustaste "Als Administrator ausführen" wählen.
Im schwarzen Feld chkdsk /f Laufwerksbuchstabe und : schreiben. (Also bei Laufwerk c sähe das so aus: chkdsk /f C: Mit Enter geht es los.
windows macht viel Mist, aber an Linux-Partitionen ist es bei mir noch nie dran gegangen.

[Sturmovik]

Zitat (expat: 25. August 2016 - 16:07)

GParted kann auch (ausgehängte) NTFS-Partitionen überprüfen.

Hast recht. Ich bin zu sehr von parted ausgegangen, gparted is ja letztlich nur ein grafisches Frontend für parted, fdisk usw. Dass das auch fsck einbindet hab ich jetzt erst bemerkt

Dieser Beitrag wurde von Sturmovik bearbeitet: 25. August 2016 - 17:43

[RalphS]

Frittiert nicht, nur paßt der Spiegel ($MFTMirr) nicht zum Original ($Mft).

- Wenn Du ganz sicher gehen willst:

-- FS Dump (als Image, notfalls per dd)
-- Windows greifen und das korrigieren lassen - evtl zunächst ohne das /f um zu schauen daß er das auch richtig hinkriegt
-- Windows neustarten und dann die Daten auf dem Volume anschauen, ob das paßt
-- Fertig.

Wenn alles okay ist, kann das Image theoretisch weg, aber aufheben ist trotzdem zumindest für ne Weile eine gute Idee; solange, bis klar ist, daß die Daten wirklich 'sauber' geblieben sind.

Wenn was schiefgehen sollte wegen Windows: Image zurückspielen.

-- Und für die Zukunft, wie ja schon erwähnt, möglichst nur von Windows aus auf NTFS schreiben.

[expat]

Zitat (RalphS: 25. August 2016 - 20:34)

-- Und für die Zukunft, wie ja schon erwähnt, möglichst nur von Windows aus auf NTFS schreiben.

Wie kommst du darauf?

[RalphS]

Ganz einfach, weil das ein WINDOWS Dateisystem ist.

Dasselbe gilt andersherum natürlich auch, unter Windows auf ext* oder reiser oder auch ZFS oder sonstwas Vergleichbares ist nicht minder problematisch.

Lesen kann man alles mögliche, da passiert - wenn der Autor des Treibers nicht grad totaler Stümper war -- nichts.

Aber schreiben hat man ganz schnell ein Problem mit der Datenintegrität. Es sei denn natürlich, NTFS wäre inzwischen quelloffen während ich nicht aufgepaßt hatte; in dem Fall hinge das bloß noch von einer vollständigen(!) Implementierung des Dateisystem ab. Oder anders gesagt, sobald die Zugriffsmethoden von Windows und anderen BS aufs Dateisystem zu 100% identisch sind (einschließlich Journalling und unvollständigen Schreibvorgängen), kann man dann auch bedenkenlos schreiben.

Dieser Beitrag wurde von RalphS bearbeitet: 26. August 2016 - 05:44

[expat]

Zitat (RalphS: 26. August 2016 - 05:42)

Ganz einfach, weil das ein WINDOWS Dateisystem ist.

Er hat ja aber von einem virtuellen windows auf eine NTFS-Partition geschrieben.

Und ich habe gestern ein Backup von windows 10, das ich mit Linux auf einer
NTFS-Partition erstellt hatte, auf eine andere NTFS-Partition zurückgespielt.
windows 10 läuft immer noch prima, was natürlich nicht selbstverständlich ist..

Dieser Beitrag wurde von expat bearbeitet: 26. August 2016 - 06:58

[RalphS]

Gut, ist jetzt die Frage, ob da eine virtuelle HDD in Linux gemountet wurde oder ob das was anderes war.

Wegen der Fehlermeldung tendier ich aber zu letzterem.

- Ansonsten, daß da was mit dem $MftMirr nicht hinhaut ist zwar selten... kommt aber vor und ist normalerweise auch kein großes Problem.

Zumindest unter Windows. Wie es aussieht, wenn da ein Linuxtreiber mitspielt - *insbesondere dann, wenn dieser nicht nach Spezifikation spielt --- ist aber ein ganz anderes Paar Schuhe.

[expat]

Meiner Meinung nach, so wie ich das Eingangpost verstehe, ist ja Linux während des Kopiervorgangs von einem virtuellen Medium (windows in Virtual Box) auf eine NTFS-Partition unsanft beendet worden. So was ist natürlich problematisch, wie man sehen kann.