Komfortabler Dateimanager mit vielen Funktionen

Datenverlust beim Kopieren

By Sven on 02.10.2007 - 12:43 in Windows Vista

Es ist der Alptraum jedes Dateimanager-Entwicklers, wenn beim Kopieren oder Verschieben von Dateien ein Datenverlust auftritt. Im Anwenderforum hatte Hornen über Probleme beim Kopieren von Dateien berichtet und festgestellt, dass beim Kopieren über das Netzwerk auch Dateien beschädigt werden. Am Wochenende ereilte mich das gleiche Schicksal. Nach dem Herunterladen von größeren signierten Installationsdateien (z.B. Office 2003 SP3) und dem Kopieren dieser auf meinen Dateiserver war ersichtlich, dass die Signatur nach dem Kopieren nicht mehr gültig war und die Datei somit verändert wurde.

Aber wie kann so etwas passieren? SpeedCommander verwendet zum Kopieren von Dateien grundsätzlich die Funktion API-Funktion CopyFileEx, die gesamte Kopieraktion (Quelldatei öffnen, Zieldatei erstellen, Dateiinhalt kopieren, Dateien schließen) wird von Windows erledigt. Zum Test habe ich mir das aktuelle Backup von SpeedCommander 12 (1120 Ordner, 15818 Dateien, 459 MiB) geschnappt und auf meinen Dateiserver kopiert. Anschließend habe ich Quell- und Zielverzeichnis mit Araxis Merge verglichen. Auf beiden Vista-Testsystemen (32- und 64-bit) sind alle derzeit über Windows-Update erhältlichen Updates installiert (inkl. Zuverlässigkeits- und Stabilitätsupdate).

Das Ergebnis war erschreckend. Araxis Merge fand ca. 30 Dateien, bei denen es Unterschiede zwischen Quelle und Ziel gab. Alle betroffenen Dateien waren größer als 1 MiB, aber nicht alle Dateien, die größer als 1 MiB sind, waren fehlerhaft. Den gleichen Test habe ich mit dem Explorer und dem Total Commander (bei aktiviertem Kompatibilitätsmodus für alle Laufwerke) wiederholt, aber Araxis Merge fand jedesmal Unterschiede zwischen Quelle und Ziel. Das Problem liegt also definitiv in CopyFileEx, da SpeedCommander, Explorer und Total Commander (bei aktiviertem Kompatibilitätsmodus) diese Funktion zum Kopieren von Dateien verwenden.

Google führte mich zu KB941673, wo zu lesen war, dass das Verhalten von CopyFileEx in Vista geändert wurde:

In Windows Vista, the CopyFile function creates a non-cached I/O request to perform a write operation. Therefore, the speed of the file copy operation is affected by the disk speed and by other resources on the older operating system.

The CopyFileBufferedSynchronousIo registry entry reverts the CopyFile function in Windows Vista to its earlier behavior. After you add the registry entry, you expect the CopyFile function to work as it would in an earlier Windows operating system. However, because Windows Explorer does not check for this registry entry, this problem occurs.

Wenn man Google mit “CopyFileBufferedSynchronousIo” füttert, dann findet man eine Menge Treffer. Die meisten Seiten empfehlen den Eintrag als Tweak für Vista, andere berichten darüber, dass damit ein Problem in Windows Backup gelöst werden kann.

Mit dem Setzen des Eintrags zwingt man CopyFileEx das “alte” XP-Verhalten wieder auf. Damit dies auch im Explorer funktioniert, muss man bei Microsoft den oben angegebenen Hotfix anfordern. SpeedCommander und Total Commander ist der Hotfix egal, sie verwenden den Eintrag automatisch nach einem Neustart des jeweiligen Programms. Beide Anwendungen kopieren anschließend das Backup-Verzeichnis wieder gewohnt zuverlässig ohne Fehler.

Ich kann also jedem, der mit Vista Dateien über das Netzwerk kopiert bzw. verschiebt, nur dringlichst empfehlen, diesen Eintrag zu setzen. Ein Nebeneffekt ist (zumindestens bei mir) eine deutlich erhöhte Datentransferrate sowie eine flüssigere und nicht mehr so abgehackte Anzeige des Fortschrittsbalkens. Wer mit der Registrationsdatenbank nicht so firm ist, der lädt sich einfach die folgende .reg-Datei

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"CopyFileBufferedSynchronousIo"=dword:00000001

herunter und doppelklickt diese anschließend im Explorer oder im Dateimanager seines Vertrauens.

Es gibt 6 Kommentare zu diesem Beitrag

Trackback URL | RSS-Feed für Kommentare

  1. Luke sagt:

    Erschreckend, aber ich sehe den Zusammenhang zu den kaputten Dateien nicht. Zumindest würde es ja bedeuten dass CopyFileEx ohne gesetzten Registry-Eintrag fehlerhaft ist und nahezu mit Garantie defekte Dateien produziert. Wenn dem wirklich so ist, wie konnte MS das nicht merken, denn Absicht hier zu unterstellen wäre schon sehr verrückt. -.-

  2. Sven sagt:

    Mit “kaputten Dateien” meine ich Dateien, die zwar genauso groß sind wie die Quelldateien, sich aber inhaltlich von diesen unterscheiden. In der Regel dreht sich das nur um ein bis drei Positionen, an denen einige Bytes (zwischen vier und zehn) nicht mit denen der Quelldatei übereinstimmen.

    Woran das nun genau liegt (Netzwerkprotokoll, fehlerhaftes Update oder Erdstrahlen), kann ich nicht sagen. Fest steht nur, dass CopyFileEx auf zwei verschiedenen Vista-Systemen (gleicher Rechner) reproduzierbar nicht korrekt arbeitet und dass mit gesetztem Registry-Eintrag bei der gleichen Kopieraktion keine Fehler auftreten.

  3. Eric sagt:

    Wäre es da nicht sinnvoll, wenn der SC den Benutzer unter Vista beim erstem Start fragt ob die Änderung automatisch vorgenommen werden soll?
    Eigentlich klingt das wirklich nach einem Albtraum, habe mir auch schon eine defekte Datei erzeugt.

  4. hanni sagt:

    ich finde das sehr krass. werde auf jeden fall mal deinen fix benutzen und auf veränderungen achten. danke dir! und nicht immer sind die erdstrahlen schuld 😉 *lol*

  5. Sven sagt:

    Für den SC12 ist es schon zu spät. Mal schauen, wie sich die Sache weiter entwickelt, ich mag eigentlich nichts mit heißer Nadel stricken.

    Ich habe in der Zwischenzeit noch ein paar Tests auf meinem zweiten Rechner gefahren, auf dem ein Vista Ultimate (32-bit) mit Updatestand 22.08.2007 installiert ist. Die Datenverluste beim Kopieren treten hier ebenfalls auf, allerdings nur, wenn man auf den Server (XP Pro) kopiert. Der gleiche Kopiervorgang auf einen anderen Vista-Rechner funktioniert dagegen tadellos (mehrmals getestet).

    Ein guter Testkandidat scheinen auch die Dateien aus dem Vista-System32-Verzeichnis zu sein. Beim Kopieren von 2405 Dateien gab es eben 114 veränderte Dateien.

  6. Sven sagt:

    Hier gehts weiter…

Top