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.