Fixed with rG4c830b240c for gpd5 but after the release. Will fix it for 2.4 too.

Also fixed for 2.4. Don't use the uninstaller on the command line, you should use the Windows method to do this.

Just to explain, if you are executing it from the command line the command line will "lock" the uninstaller until it is finished. In GUI Mode it creates a copy in %TEMP% launches this copy and exits. When run from the command line it requires a session reset to delete the unistaller. So log out / log in and the uninstaller should be removed, but the dir might still exist. I am not sure. To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.

In T7452#195836, @aheinecke wrote:

To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.

thanks for explaining what is happening and why, working with a temporary copy did the trick.

this could also help with T5952, i was testing with ansible as well.

In T7452#195841, @m.eik wrote:

this could also help with T5952, i was testing with ansible as well.

I doubt it as what Gpg4win does here is completely standard. So the win_package module should handle it or there would be multiple results if you search for "NSIS uninstall ansible"

In T7452#195845, @aheinecke wrote:

I doubt it as what Gpg4win does here is completely standard. So the win_package module should handle it or there would be multiple results if you search for "NSIS uninstall ansible"

actually, i had issues with win_package as well before now, it was the first thing i tried. installation worked as expected (except for ignoring the .ini file and not adjusting %PATH%, that's a different issue), but state: absent didn't fly. it works well with the .msi installer if you specify a proper product ID, but unfortunately not with the .exe uninstaller. only if win_package is given the path to a temporary copy of the uninstaller (not the path it was originally installed to) it does a clean uninstall.

Ok. Sorry, just to avoid debugging in case it is not known, I am pretty sure the ini file is a regression from the unicode nsis switich. The timing when it was reported to no longer work matches around that time and the installer code itself hasnt changed for even longer.