[fpc-pascal] TIniFile crash

[Michael Van Canneyt]

On Tue, 29 Jul 2025, James Richters via fpc-pascal wrote:

> I will try just creating a temp file, and once it’s completed delete the original file then rename the temp file to the correct name, it’s a good idea, and a least I will now that nothing I am doing is trying to access the file… because I can generate some random name for the temp file,  but I guess it wouldn’t stop something like antivirus from trying to scan it before I’m done.   It’s a difficult problem to figure out because it happens very rarely, but it does happen enough to be annoying.
>
> I put the delete and wait for it to be gone procedure just to make sure the file was really gone before trying to create a new one in an attempt to solve this issue, and it is well past that part of the code when the crash happens, it had already written 19 entries to the new  ini file when it crashed, and that’s why I’m confused, the error is about creating the file, but it was already created and there were already 19 successful entries to it… so what’s it creating at the point of the crash?
>
> The thing is that the file that is on the disk after the crash is only a partial file, up to the exact line that crashed, so the file must have finished the delete and there was no problem creating a new file and writing to it.
>
> I am having a suspicion that Ini.WriteString is opening the file, writing to it then closing it, which makes no sense to me, I would think that ini.create would create the file and open it, and it would remain open until ini.free..  but the fact that it sometimes gives me this message:
>
> EFCreateError: Unable to create file "I:\Programming\Gcode\Mill\Location.ini": The process cannot access the file because it is being used by another process.
>  $00603277
>
> After writing successfully 19 entries to the ini files seems to indicate
> that it’s opening and closing the file for each Ini.WriteString and that
> 1% of the time the OS didn’t finish writing the file before it was being
> opened again?  I’m just guessing here about what could cause this.

The TIniFile indeed writes to disk after every writeNNN()

There are 2 possibilities to change this behaviour:

- Set CacheUpdates to true, and call UpdateFile when done.

- Use TMemInifile, and call UpdateFile when done.
   (TMemIniFIle simply sets CacheUpdates to true in its constructor)

This should improve matters.

You can also combine this with the "use temp filename and rename" approach.

Michael.