Added a missing free in case of read error.

If I understand the code correctly the mapping is done to let the system optimize the memory management so that the full contents of the file are not kept in memory, or is there a different reason?

Maybe related, flush also does not work on Windows:

For what it's worth I found some more places where data leaked out even in log level 1. It will probably be a bit of a process to get this clean to a 100% as there is no automated way to decide what needs to be filtered and what not.

@werner
This was an issue we talked about.

There were two ways to access the registry and the config value load did not fallback to HKLM. I've removed the second way and I've tested it and it works now as it uses the codepath with the fallback.

Thanks. I've never seen that, so my test definitely did not test moving junk mails.

Hi,
As for getting Help, we all speak German ;-P

Thank you for the feedback. Very strange, that should have been solved indeed and in my tests it works and I also got feedback from other reporters who had that problem with 3.1.3 that it works in 3.1.4.

Thanks for taking the time to create this report. It should be fixed in Gpg4win-3.1.4 please try out that version. :-)

Hi Adam,

There was a report about this in the past T3956
I tried it out then with a junk folder and for me it worked so I closed the issue as a duplicate of the general moving mail problem.

I broke it a day before the release and didn't notice.
Since f34cd2782bc0cd6f359c14de4d4a889ec4e49a6e it accidentally logs all string allocations if one of DEBUG_TRACE DEBUG_MEMORY or DEBUG_DATA is set. The intention was that it should log when all three are set.

I think it has something to do with the number of files. Just encrypting / decrypting a 10GB random data file did not show a problem.

Thanks for the report. Prio High as this is data loss. I won't stop the 3.1.4 release which is currently in progress though as this issue does not appear to be a regression.

Your best bet is to try it on the command line to see if that provides some more useful output:

That is a strange failure. I don't see how that can happen without a legitimate bug.

There is now an option in the debugging tab of the GpgOL config dialog to disable async decryption. This does not fully fix the issue but maybe mitigates it for some users that are very affected by this.

I finally got around to look at your examples. Sorry for the delay. I can reproduce the issue and understand the problem.

Thanks for the report I'll look into it. Won't make it into the next release though as we are currently very close to the release.

It's implemented.

This required some changes in the keyresolver / newkeyapprovaldialog in libkleo, too.