NTFS: Verhalten des OS/Dateisystems bei Unterbrechung von USB-Datei-Transfers

[longterm]

Hallo, ich wollte gerade eine 4GB-Datei von der internen SSD auf eine externe 2 GB-Platte (korrektur: TB) kopieren. Hierbei zog ich aus Versehen das USB-Kabel. Dies führt in der Regel nicht zu Beschädigungen der Festplatte, aber die Datei ist natürlich nicht richtig kopiert. Mir fiel nun auf, dass die Datei byte-ANZAHL-genau auf der anderen Platte liegt, aber wohl nicht bit-genau (habe nicht geprüft). Was ich aber geprüft habe, ist, ob sie funktioniert: Natürlich kam eine Fehlermeldung, dass man das Backup nicht mounten könne.
Habe dann die korrumpierte Datei umbenannt und die Originaldatei nochmal kopiert und danach hat das probeweise Mounten der Kopie natürlich funktioniert.
FRAGE: Warum verhält sich das OS/das File System so? Warum zeigt es eine scheinbar konsistente, gesunde Datei an, obwohl es zu einem Fehler kam? Warum wird nicht erst am Ende des Übertragungsvorgangs der Befehl gesendet, dass die Datei als heil und ganz angezeigt werden darf? Warum erscheint sie überhaupt? Das hat doch bestimmt schon oft dazu geführt, dass Leute dann im glauben, die Datei sei dupliziert worden, das Original gelöscht haben.

 

[whats4]

weil das dateisystem erst prüft ob genügend platz am ziel ist, wenn ja, wird der benötigte platz reserviert, d.h die zieldatei angelegt, leer, das kopieren füllt diese datei, wird das unterbrochen, so ist zwar nach wie vor diese zieldatei da, aber eben nur teilweise befüllt, d.h müll. plus: Du solltest nach einem gescheiterten schreibversuch, warum auch immer, das ziel mit chkdsk prüfen, VOR dem neuerlichen versuch, damit die konsistenz sichergestellt ist. erscheinen tut die, weil sie ja am anfang des kopiervorgangs angelegt wird, und dann ist die eben da. du kannst sowas wie teracopy o.ä. verwenden, das kannst so einstellen, daß nach erfolgtem kopiervorgang per hash verglichen wird, ob bitgenau, dauert natürlich länger, weil nach kopieren nochmals komplett gelesen wird. aber das bestätigt alles nur eine ALTE weisheit: wieviele kopien braucht man von wichtigen daten?: genau, eine ZUVIEL
ergänzung: und bei einem warum auch immer gescheiterten schreiben, z.b weil die verbindung getrennt wurde, steht mindestens die fehlermeldung am bildschirm, d.h bemerken tut man sowas jedenfalls

 

[emeraldmine]

Das hat doch bestimmt schon oft dazu geführt, dass Leute dann im glauben, die Datei sei dupliziert worden, das Original gelöscht haben.

Kenne ich gut vom CD-Brennen, eine TXT gespeichert, nach so ca. 6 Monaten hatte ich doch glatt meine Software-Keys "vergessen", aaaaach, als Datei gespeichert, Rohling , Doppelklick auf die TXT Datei,
hmmm, stand was von 16Kilobyte, Inhalt = 0 Byte , ja dann besten Dank auch. *hmpf*

 

[werkam]

eine 4GB-Datei von der internen SSD auf eine externe 2 GB-Platte kopieren

Hätte ja sowieso nicht gepasst, ein 4 GB Datei passt nicht auf einen 2 GB Datenträger.

 

[longterm]

Danke!
- Ich meinte natürlich 2 TB, nicht GB :-)
- Das mit der Fehlermeldung stimmt. Jetzt weiß ich es ja. Früher dachte ich ignoranterweise aber, dass jene Dateien, die "vollständig" am Ziel erscheinen, ok sind. Wenn man mehrere sehr große Dateien kopiert, ist das vielleicht häufiger der Fall, dass man denkt, "ich guck mal, welche (vermeintlich!) heil am Ziel angekommen sind, dann muss ich die nicht nochmal kopieren." so entsteht dann der datenverlust, durch diese gutgläubigkeit/täuschung.
- Ich nutze Directory Opus und ich habe auch gute programme zum hash-vergleich hier. danke aber für den tipp mit teracopy.
- Manche Programme erstellen zuerst eine Zieldatei mit temporärem Dateinamen und benennen sie nach dem erfolgreichen Kopieren (aber ohne hashvergleich) um. Das halte ich für einen guten kompromiss. so erkennt man die unvollständigen problemkinder sofort. Ich muss mal schauen,ob man das bei DOpus einstellen kann.

Ergänzung (11. Juli 2018)

googeln nach "dopus copy to temporary file rename" (ohne anführungszeichen) brachte leider keine ersten hinweise, dass dopus das kann. dopus kann cueing und lauter nette sachen (extreme empfehlung für DOpus an dieser stelle, mit weitem abstand der beste dateimanager). falls dopus das wirklich nicht kann, muss ich das mal im forum dort erwähnen.

Ergänzung (11. Juli 2018)

aber nochmal: ich finde, ein dateisystem sollte so konstruiert sein, dass es dateien erkennt, die nicht vollständig kopiert wurden. es müsste ja einfach nur eine kurze bitfolge am ende des kopiervorgangs gesendet werden, die "vollständig" signalisiert, und wenn die fehlt, dann gibt das das signal, dass die datei das attribut "fehlerhaft/unvollständig" erhält. NTFS wird doch als superschlau gepriesen (hust), da sollte sowas doch drin sein.

 

[mensch183]

aber nochmal: ich finde, ein dateisystem sollte so konstruiert sein, dass es dateien erkennt, die nicht vollständig kopiert wurden.

In deinem Fall wurde eine Datei von einem Filesystem auf ein anderes kopiert. Keines der beiden beteiligten Filesysteme bekommt dabei überhaupt mit, dass eine Datei kopiert wird. Was passiert wirklich beim Kopieren auf ein anderes Filesystem: Bei der Quelle wird eine Datei geöffnet, gelesen und geschlossen. Beim Ziel wird eine neue erstellt (und geöffnet), geschrieben und geschlossen.

Jetzt erkennst du, dass deine obige Forderung nicht haltbar ist. Das Zielfilesystem hat gar keine Chance zu erkennen, ob die neue Datei "vollständig" ist, solange sie nicht geschlossen wurde. Du musst die also eine andere Fehlersematik einfallen lassen, die du gern hättest. Viele Dateisysteme(auch NTFS) "merken" sehr wohl beim mounten, dass sie beim letzten unmount in keinem konsistenten Zustand waren, was je nach System auf verschiedene Weisen repariert werden kann. Zaubern wird aber nix, egal ob es es forderst oder nicht.

es müsste ja einfach nur eine kurze bitfolge am ende des kopiervorgangs gesendet werden, die "vollständig" signalisiert,

Das Schließen der Zieldatei liefert genau diese Information.