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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
