benötigt CopyFile eine nachkontrolle?

Glasgow_Ranger

Hallo zusammen,

meine Frage hat folgenden Hintergrund. Ich kopiuere Daten inerhalb von einem WLAN zwischen verschiedenen Rechnern. Die Kopiererei ist dabei weniger das Problem. Wenn das WLAN jetzt zwischendurch weg ist, weil der Sender sich innerhalb des WLANs und auch außerhalb bewegt, bekomme ich da von CopyFile ne Fehlermeldung und die Funktion bricht mit 0 als Rückgabewert ab? Dann könnte ich mir eine Nachkontrolle (vergleich der beiden Dateien) ja sparen, oder?

Viele Grüße,
Ranger

Burkhi

Hallo,

du könntest auch CopyFileEx http://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx nehmen, da gibt es eine Callback Methode, die während des Kopierens aufgerufen wird und dich über den Fortschritt informiert.

Einen byteweisen Vergleich nach dem Kopieren bietet diese m.E. jedoch auch nicht an.

hustbaer

Also CopyFile tut soweit ich weiss nicht flushen bevor es zurückkommt ( CopyFileEx auch nicht).

D.h. du kannst nie sicher sein dass das File auch sicher auf den Datenträger weggeschrieben wurde auf dem es endgültig landen soll (z.B. Festplatte des File-Servers, USB-Stick etc.).

Vergleich der beiden Dateien würde ich aber keinen machen. Windows ist dafür zu "schlau" - es wird vermutlich merken dass sich seit dem rüberkopieren nix geändert hat, und die Daten aus dem Cache des Sender-PCs nehmen. D.h. es könnte sein dass der Vergleich bereits (positiv) abgeschlossen ist, bevor der Empfänger-PC die Daten noch weggeschreiben hat.

Was aber 'was bringen sollte, ist das File nach dem Kopieren aufzumachen, und dann FlushFileBuffers() drauf aufzurufen.
Wie zuverlässig das mit Netzwerklaufwerken funktioniert kann ich nicht aus Erfahrung sagen, aber grundsätzlich *sollte* FlushFileBuffers() immer garantieren dass alles sicher geschrieben wurde bevor es zurückkommt.

Glasgow_Ranger

Danke Euch erstmal.

Naja, es scheint bei Windows mal wieder in viele Konjunktive zu gehen. Es könnte gehen, es sollte funktionieren. Da könnt ihr ja nichts dafür.

Danke. Ich geb bescheid, wenn ich noch was gefunden habe.

VG,
Ranger

hustbaer

Das ist auf anderen Systemen nicht anders.

Windows garantiert bei IO Operationen dass, nachdem die Operation "haben fertig" gemeldet hat, nur mehr "unübliche" Probleme verhindern können dass sie auch wirklich komplett abgeschlossen wird (also alles "fest" auf dem Datenträger steht).

Wobei "unüblich" z.B. auch wäre wenn man ne Festplatte absteckt ohne über "sicher entfernen" zu gehen, wenn der Strom ausfällt usw.

Linux garantiert diesbezüglich auch nicht mehr.

Was diverse Probleme mit FlushFileBuffers etc. angeht: Windows garantiert dabei grundsätzlich schon dass nach Abschluss von FlushFileBuffers alles "fest" geschrieben ist. Gab nur immer wieder mal Bugs (in Windows, der HDD/SSD Firmware etc.) die diese Garantie dann gebrochen haben. Daher die vielen Konjunktive.
Und auch das ist auf Linux nicht anders. Gab z.B. lange Zeit nen Bug der fsync (=FlushFileBuffers Pendant) auf Software RAID Volumes komplett Wirkungslos gemacht hat.

Natürlich ist das nicht schön, aber damit muss man leben. Nach ein paar Jahren gewöhnt man sich dran dass das so ist, und fängt irgendwann an sich zu wundern/freuen wenn die Sachen mal irgendwann funktionieren wie sie sollten