Hi sorry, here it is. I don't see a recommended way for providing a ton of text, so just pasting it here.

The dirmngr may at any time open a file in that directory and thus there is no reliable way to remove the home directory when any gpg tool is running. Daemons need to be stopped before a directory can be deleted. So I think this is a non-issue and brought to the table only because we have that kludge of detecting a n unlinked directory on Unix. But even on Unix this is not possible to get rid of the home directory, for example if you want to umount it.

Using intptr_t works with this particular case but it does not
solve the general problem under Windows. On Windows an integer
may identify a libc file handle, a socket, and some other
objects. Despite that they are integers they are all different objects
and it is hard to distinguish them

Ok. Thank you for sharing informations!

Yep, I can access this property.

I think that it's good to rewrite enum_secret_keys in g10/skclist.c.

The bug is gone by rG79f165d7a8bc: gpg: Make --skip-hidden-recipients work again..

Please provide a complete build log or at least the output of the configure run.

Sorry, it didn't made it into 2.2.11.

I guess we can close that, right?

Released: https://lists.gnupg.org/pipermail/gnupg-announce/2018q4/000432.html

• gpgsm: Fix CRL loading when intermediate certicates are not yet trusted.
• gpgsm: Fix an error message about the digest algo. [T4219]
• gpg: Fix a wrong warning due to new sign usage check introduced​ with 2.2.9. [T4014]
• gpg: Print the "data source" even for an unsuccessful keyserver query. ​
• gpg: Do not store the TOFU trust model in the trustdb. This allows to enable or disable a TOFU model without triggering a trustdb rebuild. [T4134]
• scd: Fix cases of "Bad PIN" after using "forcesig". [T4177]
• agent: Fix possible hang in the ssh handler. [T4221]
• dirmngr: Tack the unmodified mail address to a WKD request. See commit a2bd4a64e5b057f291a60a9499f881dd47745e2f for details.
• dirmngr: Tweak diagnostic about missing LDAP server file.
• dirmngr: In verbose mode print the OCSP responder id.
• dirmngr: Fix parsing of the LDAP port. [T4230]
• wks: Add option --directory/-C to the server. Always build the​ server on Unix systems.
• wks: Add option --with-colons to the client. Support sites which​ use the policy file instead of the submission-address file.
• Fix EBADF when gpg et al. are called by broken CGI scripts.
• Fix some minor memory leaks and bugs.

So maybe closing the inspector, too is necessary here so that the real close / unload on the mail is triggered. But it might just be that Outlook immediately reopens the mail in your case. Then it won't help but I think you should try that, too because any Interprocess communication will be more effort.

It happens with 3.1.4, too.

Works nicely now. I added a "yellow" warning to indicate that the message is a crypto message that can't be handled by GpgOL in the Junk folder. I see no way to actually decrypt in the Junk folder as we are not allowed to access attachments.

In T4241#119944, @msc wrote:

I wonder if it would be possible for you to close the mail / inspector of the mail with DiscardChanges before doing a save as?

Discarding changes with the Close(OlDiscard) method has no effect on the issue.

Here are warnings:

If we can assume C99, we have the type.
I know, it is not guaranteed to be enough size. For particular host (Windows 64-bit), it works.

or, more accurately so it matches the C api, perhaps gpg.constants.import_status

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Yes, I can confirm that log entry.

Yes I see the problem and have a fix for it. I'm just trying to make it nice now :-)

Yes, I also can't decrypt the files there. As Outlook warns about
restricting access to attachments and active contents, the reason is
clear. The mail must be moved elsewhere.

I can reproduce that it won't be moved.

This issue is pretty old and I think anything here was fixed in recent releases. So let's close this to avoid artifacts in the tracker.

A wait, we have T4203 for the continuing problems. So let's close this.

This was likely one form of T4111

3.1.4 was released.

This had also something to do with the missing keycache that will be released in 3.1.5 so that sometimes S/MIME keys were not cached internally and so would not be used.

There is still at least one report claiming that this still happens for large attachments. I could not reproduce it.

This was fixed with the Gpg4win-3.1.4 release. Apologies that I forgot to mention a pre release version / installer in this issue.

I've tried to reproduce it but failed. Even If I open the message in a new window or a new explorer the message is correctly caught.

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Looking at the GPGME code the ERROR stati don't matter because they are only used to return a better error code in case an operation failed. The specific ones are not even recognized.

No info received.