I was asked to test this again with a newer version. With Gpg4win-5.0.0-beta369 not much has changed, you still can choose "Certify" on the only secret key and the certify window only allows "Cancel". Difference is only that now the "Certify with" line is empty:

This happens only in the 64-bit builds, i.e. with Gpg4win 5.

I implemented that in the old 2.2 branch for easier testing.

Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.

I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.

The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.

Here is a possible fix:

Fixed and backported for VSD 3.4 and VSD 3.3.

We were testing different things. This instance of the move to folder issue is fixed, for variants we'll open new tickets with clear test cases.

Also implemented for 2.2

The following workflow works for Markus and me:

FWIW: The fix rO75f46829054e is part of GpgOL since 2.6.3

Same behavior (on vsd-3.3.3-beta90.12 @ win10) for smime encrypted mails:

I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.

Looks good to me on vsd-3.3.3-beta90.12 @ win10:

what ever was fixed with the attached commit we can not test.

I see no workaround.
The attachments in the original mail are not gone, yes.
But the mail can't be forwarded with them.

Tested with VS-Desktop-3.3.90.12-Beta, GpgOL 6.5 (WIN10 and WIN11)

Test with 3.3.90.12-Beta:
The test mail from before does not cause a spawn cycle and no high CPU load any more. (Tested without "show as text only", as it was not relevant before.)

Looks good to me on vsd-3.3.3-beta90.12 @ win10 (temporary filename is now attachment.odt or e.g. attachment (002).odt)

Debug log for vsd:

Also still present on vsd-3.3.3-beta90.12 @ win10 (mail is not moved)

After a discussion we decided to drop the idea to save the status of the check boxes even for only the box "encrypt for others".

Current logs for a forever hang:

still reproducible on gpg4win-5.0.0-beta369 @ win10