kizu schrieb:
Eine Fehlermeldung gibt es (zumindest in der GUI) nicht.
Ist ja dann sehr gut durchdacht von LXQt, andere DEs schaffen das. 😛
Ich vermute mal, da das Dateisystemn ja erfolgreich lesend eingebunden ist
Das würde sich ja leicht überprüfen lassen durch die Ausgabe von
mount
Würde aber gegen die Standard-Handhabung laufen, die da lautet: Gar nicht einbinden, Meldung ausgeben, dass das unter Windows gemacht werden soll.
(wo würden wir eine Fehlermeldung sehen können? In irgendeinem Log?).
Beim manuellen Einbinden mit mount, wenn der Dateimanager selbst keine ausgibt. Auch in der Ausgabe des Kernelringpuffer dürfte dazu etwas stehen.
An die Daten kommt man ran, aber die Frage ist halt, ob wir ohne Windows eine (am besten sichere) Möglichkeit haben, auch den schreibenden Zugriff zu bekommen.
Nein, siehe oben. Das wird nicht umsonst nicht eingebunden, sondern weil durch genau den Weg, den Windows da geht, nunmal Datenverlust droht. Dafür gaukelt es dem Nutzer aber einen schnelleren Start vor, ist ja viel wichtiger als Datensicherheit...
Ich habe
gefunden, und den Parameter -d, der aber anscheinend nur den Flag entfernt. Wird dadurch das Dateisystem nicht vorher geprüft und somit dem Datenverlust vorgebeugt?
Die Prüfung des Dateisystems (was ntfsfix eben NICHT tut) beugt keinem Datenverlust vor. Wenn das Dateisystem kaputt ist ist es bereits zu spät. Die Ursache für den unsicheren Status des Dateisystems kennst du ja, das ist der Windows-Schnellstart. Das will Microsoft also so.
Und nein, ntfsfix sollte man tunlichst nicht benutzen, wenn man seine Daten noch nutzen will. Steht aber auch eindeutig in der manpage, dass es nur "grob" arbeiten kann.
Wodurch genau entsteht denn die Gefahr des Datenverlustes?
Dadurch, dass das Dateisystem von Windows nicht ausgehängt wird und somit in einem "unsicheren Status" verbleibt.
Durch das Mounten in Linux, ohne dass das Dateisystem ordentlich geschlossen wurde (wird das durch den oben genannten Befehl nicht gemacht? Wenn nicht: Warum nicht?) oder dadurch dass Windows später das Dateisystem wieder öffnet und dann "Fehler" erkennt und beim reparieren der Partition die Daten wieder löscht?
Das Einhängen in Linux hat nichts damit zu tun, das Dateisystem wird von Windows in diesem Zustand belassen, sonst gäbe es ja das Problem gar nicht...
Und nochmal: ntfsfix ersetzt NICHT das aushängen des Dateisystems, das Windows NICHT durchführt, wenn Fast Boot verwendet wird. Und ja, Microsoft hält das nicht für einen Bug, sondern für ein Feature. Genau aus dem Grund, dass durch das Windows-Verhalten Datenverlust beim Einbinden droht, werden in einem solchem Zustand zurückgelassene Partitionen von Linux-Distributionen nicht eingebunden, eben um Datenverlust zu verhindern. Heise hat das mal schön erklärt (gilt auch für Windows 10, da die selbe Technik dahinter).
Windows "löscht" da auch nichts "beim reparieren", CHKDSK kann auch nur das reparieren, was noch nicht verloren ist.
