Arbeitet binärer Vergleich auch mit Disketten?

[Wilhelm M.]

Hallo!
Habe in letzter Zeit mehrmals auf diese antiken Datenträger zurückgegriffen (ihr wisst schon, diese dünnen Plastikdinger... ) und dabei Seltsames entdeckt.
Wenn ich eine Datei auf die Diskette schreibe, verifiziere ich fast immer mittels eines binären Vergleiches. Mir fiel auf, dass das unglaublich schnell ging - ruck zuck fertig. Bei einer Dateigröße von ca 1MB. Disketten sind ja nicht gerade schnell, also war das schon einmal komisch. Und dann passierte es: eine Datei konnte wegen eines Diskettenfehlers nicht mehr kopiert werden. Aber: der binäre Vergleich ergab noch immer keinen Fehler! D.h. die Datei auf Diskette war - angeblich - mit der Datei auf dem Quellmedium identisch.

Bug oder nicht Bug - das ist hier die Frage...

[Hacker]

Bug oder nicht Bug - das ist hier die Frage...

Windows Cache. Die Diskette einmal rausnehmen und wieder reinschieben, dann denkt das Laufwerk (und teilt es auch Windows mit) es waere eine andere.

HTH
Roman

[Wilhelm M.]

Also Du meinst, wenn man die Diskette drinnen lässt, dann vergleicht TC zwischen der Quelldatei und der Kopie im Windows Cache?
[Edit]D.h. also, dass man den binären Vergleich nur mit Einschränkungen zum Verifizieren von Dateikopien verwenden kann? Beim Kopieren zwischen 2 Partitionen kann man ja nicht einmal die Diskette auswerfen und wieder einlegen...

[Hacker]

Also Du meinst, wenn man die Diskette drinnen lässt, dann vergleicht TC zwischen der Quelldatei und der Kopie im Windows Cache?

Ja.

D.h. also, dass man den binären Vergleich nur mit Einschränkungen zum Verifizieren von Dateikopien verwenden kann?

Da bin ich mir nicht sicher, sorry.

Roman

[icfu]

D.h. also, dass man den binären Vergleich nur mit Einschränkungen zum Verifizieren von Dateikopien verwenden kann?

Ja, sicher verwenden kannst Du ihn nur für alle Dateien, die größer sind als der eingestellte Cachewert beim Kopieren von großen Dateien, nur dann wird der Diskcache umgangen. Wenn die Dateien auf verschiedenen Platten liegen, ist dieser Schwellenwert nicht gerade groß, also kannst Du bei einer einzelnen Datei, die Du gerade frisch kopiert hast, fast sicher sein, daß sie aus dem Diskcache gelesen wird.

Das kannst Du auch selbst testen, kopier einfach mal 'ne Datei, die kleiner ist als der o.g. Schwellenwert, von Partition C nach D und wieder zurück, danach machst Du einen Dateivergleich, Du wirst keine Platte hören.

Da müßte ghisler mal ran, meine ich, eigentlich dürfte es nicht sein, daß Dateivergleiche über den Dateicache laufen.

Wenn Du ein richtiges verify machen willst, mußt Du auf externe Tools zurückgreifen, beispielsweise http://www.xxcopy.com mit /V2 switch, auch das Verhalten des Caches läßt sich damit regulieren, mit /CA0 schaltest Du ihn aus.

Beispiel:
xxcopy "X:\pfad\zur\quelldatei" "Y:\pfad\zum\zielordner" /ca0 /v2

Icfu

[ghisler(Author)]

Leider habe ich bisher keine Funktion gefunden, um den Cache zu leeren...

[icfu]

Du kannst ihn doch umgehen?

Frisch kopierte Dateien, die kleiner sind als CopyHugeBlockSize und auf der gleichen Platte liegen, werden aus dem Diskcache gelesen, Dateien die größer sind werden immer ohne Diskcache verglichen.

Das kam jedenfalls bei meinen Tests hier raus, allerdings habe ich mich auf das Rödeln der Platte verlassen. Liege ich da falsch?

Icfu

[ghisler(Author)]

Das wäre aber sehr langsam, und funktioniert auch nur mit mehrfachen der Clustergrösse...

[Norbert]

Der Cache lässt sich umgehen wenn man CreateFile mit dem Flag FILE_FLAG_NO_BUFFERING benutzt.

[icfu]

Wie ich bereits sagte, es funktioniert ja bereits JETZT im Syncdialog, weil alle Dateien, die größer als CopyHugeBlockSize sind, IMMER vom Datenträger selbst gelesen werden, unabhängig davon, ob ich sie vorher per Kopieraktion in den Diskcache transportiert habe oder nicht, deshalb meine Verwunderung. Dafür muß es doch eine Erklärung geben, kann ja sein, daß ich Tomaten auf den Augen (bzw. Ohren) habe.

Was die Clustergröße damit jetzt zu tun hat, weiß ich nicht, vielleicht ein Mißverständnis. Ich weiß nur, daß ein Synctool, das nicht den Cache umgeht, gefährlich ist, weil es die Anwender in falscher Sicherheit wiegt.

Wenn eine CD verhunzt wird und das Synctool "Alles paletti" ausspuckt, bloß weil der Anwender dummerweise zuviel RAM verbaut hat, ist das nicht gerade eine Einladung dafür, das Synctool zu verwenden, um CDs o.a. Datenträger auf Unversehrtheit zu überprüfen.

@Norbert:
Das klingt ja gut, hoffen wir mal, daß das auch umgesetzt wird.

Icfu