From time to time I do something similar - writing to log files with FILETOSTR() / STRTOFILE(), writing separate log entries in rapid succession. I have never seen any of those operations fail, and I've never had to check the return value of STRTOFILE(). The log files have ranged in size up to about 150KB.

If you want to get to the bottom of this issue I'd first try running with AV disabled. This is easy with most products unless you're in a corporate/locked-down environment.

Failing that:

- I assume there's no possibility of concurrency - some other process accessing your files at the same time

- You're writing your files to a true Windows file store, not something like an old NAS box

>You are probably right. The AV is actively running, and does eventually get written. The AV is probably what I am believing to be a buffer. After the AV finishes its thing, it then writes it. Until then my program only see the last written. Right?
>
>But I have resolved the problem by checking to see if the file was written correctly. Minimal performance hit.
>
>>For this kind of weirdness the first suspect should always be antivirus software. It hooks the file system - basically, file I/O is not allowed unless AV allows it, and even then, file contents are not accessible until AV has finished processing it (which can introduce timing issues). Can you re-test with it temporarily disabled, or with the working folders (including temp files folder) excluded from real-time scanning?
>>
>>Are you running any other software that may hook the file system, such as so-called "real-time" backup software, or similar?
>>
>>>Ok, problem solved.
>>>
>>>I checked the value returned from the StrToFile. It is the length written. If 0, then it tries to write again. It while continue trying up to 10 times before responding with a failure to write. Still like to know why I have to do this.
>>>
>>>>Hi all,
>>>>
>>>>I should know this solution, but I can not seem to solve it.
>>>>
>>>>In a my code I have a point where a file is read in a variable (FileToStr). The string is modified and then written back to the file (StrToFile). This is done multiple time, very quickly. The problem is that file content that is read is not the file previous written, but the one prior to the writing. It appears that it is reading from the file, but writing to a staging buffer before actually writing to the disk. Therefore the reading does not see the recent changes.
>>>>
>>>>Does anyone have any suggestions? Perhaps flush the buffer?
>>>>Or I should use low-level file functions? Or would that add a performance hit?