I have been using two tools to add additional data to my executable files in post build scripts for years:
Both tools open the freshly built executable and append chunks of data to it. And both started to fail with the error “[project].exe is open in another program” more often lately.
I never managed to find out exactly what causes the problem. First I suspected BitDefender antivirus, but the error still occurs after I have switched to Windows Defender, so it’s not just BitDefender but probably any antivirus software that is causing the trouble.
As a first try I added a 2 seconds delay between the compiling/linking and the execution of each of these tools. It seemed to help, the errors became much less frequently but they still occurred. Also those 4 seconds always felt like eternity (the whole compile usually takes less than 10 seconds, so 4 additional seconds is a whopping 40%).
So, a few days ago I had enough. I’ve got the source code of these tools, so why not simply add several tries to opening the file? That’s what I did: Both tools now try to open the file and if that fails wait for a second and try again. Rinse and repeat up to 10 times. In my tests, it rarely took more than 2 tries, usually the first one succeeded. That means it shaved these 4 seconds off the build time again with the rare exception of adding them again at very few occasions.
The changes to assemble are in the GnuGettext svn repository.
And here is a patch to jcldebug.pas which I used for MakeJclDbg. (If somebody wants to submit this as a pull request on github, go ahead.)