Flush File Buffers

[moises1953]

Windows has a FlushFileBuffers function to move the pending data from cache to file, without closing the file:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-flushfilebuffers
I'm interested in implement this function but need the windows file handle, and FILEATTR has not been implemented.
There is any way to perform fileflushing?.
Posible to add a _FILEFLUSH statement (or similary) to QB64?

[doppler]

The only reason windows has the flush function is to accelerate closing and flushing files.  Normally windows will flush at idol times or when a threshold is meet.  The only reason I have had to use a flush function program is when I can't remove a external drive (eject/unmount).  Such as when I can not remove a flash drive because some program is using it. (none really are).  External devices are the last to get flushed.  Hence it seems slow.

As far as QB64 needing it.  QB64 is not fast enough to reach windows threshold.  And any records written out but not flushed are in memory cached.  Quick re-access.  Close and reopen a file will commit a flush faster.  So just use close and reopen.

PS. Beside you can always use a dos shell to execute a flush. (call your program)

[moises1953]

Thank's doppler for your help.
The implementation of FILEATTR may solve the problem:
handle=FILEATTR(fileno, 2)

[Dav]

I was wondering...would doing a SEEK to EOF make the file system flush first before seeking?

- Dav 

[FellippeHeitor]

You could just CLOSE the file handle and then OPEN it again - I believe the flushing would occur immediately.

[Petr]

I may not have understood the problem right at the beginning of the thread, but:

If you are in the file opened as record number 1 in the mode for binary access and you are in the position, say, byte 150 in the file, then you get the rest of the file as GET 1, LOF (1) - SEEK (1), REC $ where REC $ is fixed a string of length LOF (1) - SEEK (1).

I think it can be solved, it just depends on the way you open the file. I assume that QB64 is fast enough for that (when I write about 1 gigabyte with QB64 to disk in a very short time). When you open a file in a new block of memory (MEMNEW), you gain direct access to the data in memory and you have directly accessible your own cache equivalent.

[moises1953]

In Windows, cache is a self-contained subsystem that follows its own criteria for data flow from a file cache to disk, regardless of the readings that are made, and even if it is closed.
The two easy ways to ensure the data integrity of a transaction on a file is:
1) Move data at the end of transaction by calling FlushFilebuffers in the case of Windows
2) Open file without cache, making it more slow

Say that, if you capture a set of data that may be recorded in a file, it's a good practice to call FlushFilebuffers at the end of all recordings (not every put), that informs to cache subsystem to move data to disc, without a need to close the file. But to do this, is necesary to use handle=FILEATTR(fileno, 2) and use this obtained handle in the call to FlushFilebuffers from the windows API, unless another way is implemented.

EDIT: May be FellippeHeitor tesis, that on close the system flushes the data, is correct, but needs the filename to reopen.