[fpc-pascal] TIniFile crash

[James Richters]

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. 

James
 
 
From: fpc-pascal <fpc-pascal-bounces at lists.freepascal.org> On Behalf Of Ralf Quint via fpc-pascal
Sent: Tuesday, July 29, 2025 2:26 PM
To: fpc-pascal at lists.freepascal.org
Cc: Ralf Quint <freedos.la at gmail.com>
Subject: Re: [fpc-pascal] TIniFile crash
 
On 7/26/2025 2:05 PM, James Richters via fpc-pascal wrote:
I’m having an issue with TIniFile, 
I have a pretty simple procedure,  It deletes the old .ini file, waits for it to be gone,  creates a new one, writes a bunch of variables to it, then frees it.  It works 99% of the time, but 1% of the time it crashes right in the middle of writing the file.  The previous one was really deleted because there is nothing left of the original after the crash, it contains only lines up to the failure.  I just don’t see what I am doing wrong and I am hoping someone can help me figure out how to fix this.
This is a single thread console application created with FreePascal with out Lazarus, and this file is not used by anything else.  I just happened to catch it this time and I was sitting right here and nothing else was accessing Location.ini when the crash happened.
This happens on multiple difference computers.  Most of which have no purpose other than to run this one program, so there is never anything else even open in the system at all.

Anyone have any idea why this is happening and how I might be able to prevent it?
Below is the crash and related source code.
To narrow down where and why this would crash, you might want to try and use some different procedure. Just going by a guts feeling, I guess your problem is caused by this "waiting until the ini file is really deleted" procedure.
To test this, please try to write the contents to the new .INI file, deleting the old one and then rename the new one. I suspect that in this order of things, it will not crash while writing to the new file...
If it does still crash, then the problem is within the writing of the contents of the .ini file, otherwise this smells like some timing issue introduced due to that waiting procedure, possibly in connection with the OS file caching...
 
Ralf
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20250729/7c0fd37c/attachment-0001.htm>