Dateipuffer für Diskettenlaufwerk zurückschreiben

Fragen rund um diverse Windows-Versionen, ihr Verhalten unter Xbase++ und den Umgang mit der API

Moderator: Moderatoren

Antworten
Rolf
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 258
Registriert: Do, 27. Apr 2006 12:28
Wohnort: Görlitz

Dateipuffer für Diskettenlaufwerk zurückschreiben

Beitrag 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
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag 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
Rolf
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 258
Registriert: Do, 27. Apr 2006 12:28
Wohnort: Görlitz

Beitrag 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
Zuletzt geändert von Rolf am Do, 16. Nov 2006 10:55, insgesamt 1-mal geändert.
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag 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?
Rolf
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 258
Registriert: Do, 27. Apr 2006 12:28
Wohnort: Görlitz

Beitrag 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
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag 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
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag 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 !
Gruß
Hubert
Rolf
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 258
Registriert: Do, 27. Apr 2006 12:28
Wohnort: Görlitz

Beitrag 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
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag von Lewi »

1.7?
Da muß ich passen. Ich arbeite mit xBase++ seit der Version 1.80
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag 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.
Gruß
Hubert
Rolf
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 258
Registriert: Do, 27. Apr 2006 12:28
Wohnort: Görlitz

Beitrag 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
Antworten