Die ganze Sache hat mir keine Ruhe gelassen, daher habe ich gestern noch weitere Tests durchgeführt. Bisher hatte ich immer nur auf meinen Dateiserver kopiert, wenn auch von zwei verschiedenen Rechnern. Um auszuschließen, dass das Problem mit dem Dateiserver zusammenhängt, habe ich die Testdaten nun über Kreuz kopiert, d.h. vom Vista des einen Rechners auf ein XP des anderen sowie vom Vista des anderen auf das XP des einen Rechners. Erstaunlicherweise wurden die Daten hierbei ohne Fehler kopiert. Auch die Kopien auf mein Notebook waren fehlerfrei.

Damit scheint festzustehen, dass der Datenverlust beim Kopieren kein allgemeines Problem von Vista ist, sondern mit der Konfiguration meines Dateiservers zu tun haben muss. Auf dem Server läuft ein RAID-1, welches an einem zusätzlichen SIL3112-Controller (Silicon Image) angeschlossen ist. Probleme gab es damit bisher nicht, auch das RAID-Statusprogram und die Ereignisanzeige zeigen keine Fehler an. Trotzdem habe ich das RAID aufgelöst, die beiden Festplatten wieder an den Onboard-RAID-Controller (VIA VT8237) angeschlossen und erneut ein RAID-1 erstellt.

Erneute Tests mit dem nun neuen RAID-1 funktionierten wiederum fehlerfrei. Das heißt also, dass die Kopierfehler irgendetwas mit der alten RAID-Konfiguration zu tun haben müssen. Warum sie dann aber bei gesetztem “CopyFileBufferedSynchronousIo” nicht auftraten, dafür habe ich keine Erklärung. Den Eintrag “CopyFileBufferedSynchronousIo” werde ich aber trotzdem aktiviert lassen, da damit die Datentransferrate beim Kopieren über das Netzwerk spürbar angehoben wird.

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.