Seite 1 von 1
Dateipuffer für Diskettenlaufwerk zurückschreiben
Verfasst: Do, 16. Nov 2006 9:14
von Rolf
Hallo
Gibt es einen API-Befehl der den Dateipuffer für das Diskettenlaufwerk zurückschreibt? So in der Art wie COMMIT bei Datenbanken.
Es geht darum eine Diskette zu prüfen. Also wenn Datei wieder herunterkopiert werden kann, ist alles Ok.
Aber in der Regel liegt die Datei noch in irgendeinem Speicher.
Ich habe schon mit sync.exe V2.0 von sysinternals.com probiert. Funktioniert so wie ich es möchte, aber ich will eigentlich keine EXE mitschicken.
Gibt es da so etwas?
Grüße Rolf
Verfasst: Do, 16. Nov 2006 9:45
von Lewi
Guten Morgen Rolf,
der Hintergrund Deiner Frage ist mir nicht ganz klar.
Willst Du etwas von der Diskette kopieren oder auf die Diskette?
Wenn Du etwas von der Diskette kopieren willst und dies schlägt fehl, dann braucht doch nichts auf den Datenträger kopiert zu werden. Oder?
Wenn Du etwas auf die Diskette speichern willst und dies schlägt fehl, dann bekommst Du in Zusammenhang mit FWirte() und FError() mögliche Fehlerursachen geliefert. Beim Lesen vom Datenträger über FRead() und FError() ebenfalls.
Im übrigen würde ich z.B. die Datei zunächst in ein TEMP-Verzeichnis kopieren. Erst wenn der Kopiervorgang als solches komplett abgeschlossen wurde, kann anschließend die Bearbeitung der Datei erfolgen.
Viele Grüße
Olaf
Verfasst: Do, 16. Nov 2006 10:09
von Rolf
Hi Lewi
Meine Anwendung erzeugt eine Datei.
Diese wird von einem Fremdprogramm überprüft, verschlüsselt und auf eine Diskette gespeichert.
Danach wird die Diskette verschickt und nach etwa zwei Wochen wird man informiert das irgendetwas nicht stimmt. In der Regel ist die Diskette defekt.
Wir haben früher immer die Datei von der Diskette kopiert und wenn das ging war alles ok. Doch jetzt kommt die Datei aus dem RAM aber nicht mehr von der Diskette.
Funktionieren würde es, wenn zwischen dem Prüfen noch mal eine leere Diskette im Laufwerk war, aber das kann man dem Anwender ja nicht unbedingt zumuten.
Code: Alles auswählen
LOCAL cSource := ""
LOCAL cTarget := ""
Msgbox("1. Datei auf Diskette kopieren")
cSource := "c:\Temp\1106\test.con"
cTarget := "a:\test.con"
COPY FILE (cSource) TO (cTarget)
Msgbox("2. SYNC ausfuehren")
RUN SYNC.EXE -r A
Msgbox("3. Datei von Diskette zurueck kopieren")
cSource := "a:\test.con"
cTarget := "c:\Temp\1106\test.co2"
COPY FILE (cSource) TO (cTarget)
Msgbox("4. fertig")
Mit 'RUN Sync.exe' hört man das Diskettenlaufwerk, ohne würde man nichts hören. Funktioniert auch wenn man unter Windows 2000 die Datei von Hand hin und her kopiert. Wenn man die "Dateien fliegen sieht" (Fortschrittsanzeige) kommt sie von der Diskette, ansonsten kommt sie aus dem RAM.
Hab einen Befehl gefunden heißt
FlushFileBuffers
Weiß aber nicht warum der nur unter Administartionsrecheten laufen soll hab die sync.exe auch mit eingeschrenkten rechten ausführen können und hat auch funktioniert.
Grüße Rolf
Verfasst: Do, 16. Nov 2006 10:41
von Lewi
Habe ich es richtig verstanden, dass die Verschlüsselung im RAM statt findet, und dass dem Verschlüsselungsprogramm die Ausangsdaten als String übergeben werden, statt wie früher, die Daten von einem Datenträger einzulesen und dann zu verschlüsseln? Und das anschließend die verschlüsselte Datei als String vom Verschlüsselungsprogramm zurückgegeben wird und eure Anwendung dafür Sorge tragen muß, dass die (verschlüsselten) Daten auf den Datenträger kopiert werden?
Verfasst: Do, 16. Nov 2006 10:53
von Rolf
Hi Lewi
NEIN
Das Programm schreibt die Datei auf die Diskette (nur auf die Diskette). Die Datei liegt aber dennoch im RAM (bzw. in irgendeinem Buffer).
Wenn ich die Datei dann nach C:\Temp\ kopiere geht das sehr fix, da sie nur aus dem Buffer geschrieben wird und nicht von der Diskette in den Buffer eingelesen und dann geschrieben wird.
Windows schaut glaube ich nur nach ob die Diskette drin ist und die Datei drauf ist. Die Daten kommen aber irgendwie aus dem Buffer.
Ich experimentiere gerade mit FRead und...
Grüße Rolf
Verfasst: Do, 16. Nov 2006 11:11
von Lewi
Es geht Dir also darum festzustellen, ob die Daten nach der Verschlüsselung vom Datenträger zu lesen sind.
Ich gehe mal davon aus, dass das Verschlüsselungprogramm eine Fehlermeldung generiert, wenn beim Schreiben der Daten auf der Diskette ein Fehler aufgetreten ist. Falls nicht, stellt sich sich das Problem, dass Du die Diskettendaten nur unzureichend verifizieren kannst. Über Fread() könntest Du zumindest feststellen, ob Du alle Bytes einer Datei lesen kannst. Oder Du kopierst die Dateien mittels FCopy() zum Test auf die Festplatte. Im Gegensatz zu COPY FILE erhälst Du Fehlerhinweise.
Gruß, Olaf
Verfasst: Do, 16. Nov 2006 11:16
von brandelh
Hallo Rolf,
in dem Moment wo eine Datei auf Diskette geschlossen wird, werden auch die Puffer auf die Diskette geschrieben (Licht leuchtet beim Schreiben). Dass die zusätzlich noch im Cache für das Diskettenlaufwerkes liegt ist richtig, stört aber nicht.
Man könnte Diskette entnehmen, neu einlegen und dann mit z.B. dem COMP (Betriebssystem) oder den F-Filefunktionen einen Binärvergleich durchführen, aber die meisten Diskettenfehler kommen erst durch den Versand !
Verfasst: Do, 16. Nov 2006 11:34
von Rolf
@Hubert
Mein Chef hatte über 12 Jahre keine großartigen Probleme mit den Disketten, doch nach der Änderung des Fremdprogramms haben wir sehr oft Probleme und wir stehen immer wieder dumm da.
@Olaf
Ab welcher Version gibt es FCopy wir haben leider noch die 1.70.
und ich benutze in der Regel den API-Befehl.
Ich glaub das Fremdprogramm meckert nicht, hab ich noch nicht mitbekommen.
Wir haben auch vor immer eine Datei auf der Festplatte zu sichern.
und auf eine Zweitdiskette zu speichern.
Grüße Rolf
Verfasst: Do, 16. Nov 2006 11:40
von Lewi
1.7?
Da muß ich passen. Ich arbeite mit xBase++ seit der Version 1.80
Verfasst: Do, 16. Nov 2006 11:48
von brandelh
Hallo,
Ich habe früher gerne mit RUN XCOPY etc. gearbeitet, wobei der Rückgabewert in RUNSHELL besser auszuwerten ist.
Da die Rechner alle schneller wurden, die Diskette aber nicht würde ich versuchen die Dateien auf Festplatte zu erzeugen, dann kopieren (egal ob mit FOPEN() FREAD() FWRITE() etc. die gab es schon in Clipper -> Filefunktionen oder ob mit runshell xcopy ...). Dann Diskette raus und wieder rein (erkennt das BS eine neue Diskette ?) und beide Dateien entweder mit run COMP x1 X2 (Befehl des BS oder mit FOPEN FREAD etc.)
vergleichen.
Verfasst: Do, 16. Nov 2006 12:12
von Rolf
Hi
brandelh hat geschrieben:Man könnte Diskette entnehmen, neu einlegen
Ich hab es jetzt zwar mit der API-Funktion - FlushFileBuffers hinbekommen. Aber deine Lösung Hubert ist echt die einfachste und das ist ja auch vom Anwender nicht zuviel verlangt!
Vielen Dank für eure Mühe
Grüße Rolf