Hallo Leute,
vielleicht kann mir jemand weiterhelfen?
Bekanntlich verwendet Windows für Dateioperationen einen Zwischenspeicher. Öffne ich nun mit "OpenFile" eine bereits bestehende Datei für Lese- und Schreibzugriffe, dauert es mitunter mehrere Sekunden bis Windows nach einem Schreibbefehl mit anschließendem "CloseFile" den Zwischenspeicher leert, und die Datei wirklich auf die HD schreibt.
Nun meine Frage: Gibt es einen Trick (z.B. einen API-Befehl) der Windows zwingt den Datenpuffer sofort zu leeren (oder sogar auszuschalten), damit Schreiboperationen direkt (ohne Zwischenspeicherung) ausgeführt werden?
Zwischenspeicher bei Dateioperationen umgehen...
-
Kübelgrütze
- Beiträge: 8
- Registriert: 22.11.2004 18:44
-
Kübelgrütze
- Beiträge: 8
- Registriert: 22.11.2004 18:44
evtl damit:
The FlushFileBuffers function clears the buffers for the specified file and causes all buffered data to be written to the file.
BOOL FlushFileBuffers(
HANDLE hFile // open handle to file whose buffers are to be flushed
);
Parameters
hFile
An open file handle. The function flushes this file's buffers. The file handle must have GENERIC_WRITE access to the file.
If hFile is a handle to a communications device, the function only flushes the transmit buffer.
If hFile is a handle to the server end of a named pipe, the function does not return until the client has read all buffered data from the pipe.
Windows NT: The function fails if hFile is a handle to console output. That is because console output is not buffered. The function returns FALSE, and GetLastError returns ERROR_INVALID_HANDLE.
Windows 95: The function does nothing if hFile is a handle to console output. That is because console output is not buffered. The function returns TRUE, but it does nothing.
Return Values
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
The WriteFile and WriteFileEx functions typically write data to an internal buffer that the operating system writes to disk on a regular basis. The FlushFileBuffers function writes all of the buffered information for the specified file to disk.
You can pass the same file handle used with the _lread, _lwrite, _lcreat, and related functions to FlushFileBuffers.
The FlushFileBuffers function clears the buffers for the specified file and causes all buffered data to be written to the file.
BOOL FlushFileBuffers(
HANDLE hFile // open handle to file whose buffers are to be flushed
);
Parameters
hFile
An open file handle. The function flushes this file's buffers. The file handle must have GENERIC_WRITE access to the file.
If hFile is a handle to a communications device, the function only flushes the transmit buffer.
If hFile is a handle to the server end of a named pipe, the function does not return until the client has read all buffered data from the pipe.
Windows NT: The function fails if hFile is a handle to console output. That is because console output is not buffered. The function returns FALSE, and GetLastError returns ERROR_INVALID_HANDLE.
Windows 95: The function does nothing if hFile is a handle to console output. That is because console output is not buffered. The function returns TRUE, but it does nothing.
Return Values
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
The WriteFile and WriteFileEx functions typically write data to an internal buffer that the operating system writes to disk on a regular basis. The FlushFileBuffers function writes all of the buffered information for the specified file to disk.
You can pass the same file handle used with the _lread, _lwrite, _lcreat, and related functions to FlushFileBuffers.
PB / jaPBe jeweils aktuellste Version, seit 3.62 dabei, XP sp3 de/en & W7 en
Eigentlich wollte ich mit meiner Antwort ja erreichen das der Poster hier mal SELBER nach kuckt in der Win-Api, anstatt hier alles zu präsentieren.
Aber Wichtel hat ja schon den entsprechenden Part gezeigt.
Anwenden kann man das in etwa so: (Createfile gibt das echte Filehandle zurück, aber nur wenn kein #PBAny verwendet wird)
Aber Wichtel hat ja schon den entsprechenden Part gezeigt.
Anwenden kann man das in etwa so: (Createfile gibt das echte Filehandle zurück, aber nur wenn kein #PBAny verwendet wird)
Code: Alles auswählen
#NR=1
fnr=CreateFile(#NR,"C:\TEST.TST")
Debug fnr
If fnr
WriteStringN("IT CAN BE DONE")
Result=FlushFileBuffers_(fnr)
MessageRequester("Info","stop "+Str(result),0)
CloseFile(#NR)
EndIf Rings hat geschrieben:ziert sich nich beim zitieren
-
NicTheQuick
- Ein Admin
- Beiträge: 8820
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
PureBasic hat auch noch eigene Handles.
Am Beispiel von [c]OpenWindow()[/c] ist die [c]#WindowID[/c] nicht gleich der [c]WindowID()[/c], weil [c]#WindowID[/c] das PureBasic-Handle ist uns selbst bestimmt werden kann und [c]WindowID(#WindowID))[/c] das echte "API-Handle" zurückgibt, das man dann mit der API nutzen kann.
Schreibst du jetzt [c]OpenWindow(1, ...)[/c] bekommst du als Rückgabewert das "API-Handle" zurück und hast dein PB-Handle (hier 1) selbst bestimmt.
Schreibst du aber [c]OpenWindow(#PB_Any, ...)[/c] bekommst du als Rückgabewert das PB-Handle zurück, das dann automatisch ausgewählt wurde und kannst erst mit [c]WindowID()[/c] das "API-Handle" bestimmen.
Klingt vielleicht etwas kompliziert, ist aber auch schlecht gelöst vom PB-Entwickler. Vor allem wegen der gleichen Namensvergabe in der Hilfe und überhaupt für den Befehl.
Bei den Dateioperationen mit [c]OpenFile()[/c] usw. sieht das ganze aber genauso aus.
Das selbe System ist bei den meisten Libraries verwendet worden. Aber erst seit PB-Version 3.91.
Am Beispiel von [c]OpenWindow()[/c] ist die [c]#WindowID[/c] nicht gleich der [c]WindowID()[/c], weil [c]#WindowID[/c] das PureBasic-Handle ist uns selbst bestimmt werden kann und [c]WindowID(#WindowID))[/c] das echte "API-Handle" zurückgibt, das man dann mit der API nutzen kann.
Schreibst du jetzt [c]OpenWindow(1, ...)[/c] bekommst du als Rückgabewert das "API-Handle" zurück und hast dein PB-Handle (hier 1) selbst bestimmt.
Schreibst du aber [c]OpenWindow(#PB_Any, ...)[/c] bekommst du als Rückgabewert das PB-Handle zurück, das dann automatisch ausgewählt wurde und kannst erst mit [c]WindowID()[/c] das "API-Handle" bestimmen.
Klingt vielleicht etwas kompliziert, ist aber auch schlecht gelöst vom PB-Entwickler. Vor allem wegen der gleichen Namensvergabe in der Hilfe und überhaupt für den Befehl.
Bei den Dateioperationen mit [c]OpenFile()[/c] usw. sieht das ganze aber genauso aus.
Das selbe System ist bei den meisten Libraries verwendet worden. Aber erst seit PB-Version 3.91.
Genau deswegen mache ich keine PBAny rein. Iss zuverwirrend.NicTheQuick hat geschrieben: Das selbe System ist bei den meisten Libraries verwendet worden. Aber erst seit PB-Version 3.91.
Ausserdem hab ich immer gerne direkte Pointer/Objects als rückgabewerte.
Rings hat geschrieben:ziert sich nich beim zitieren
-
Kübelgrütze
- Beiträge: 8
- Registriert: 22.11.2004 18:44
