The issue is resolved in gpg4win-5.0.0-beta479 @ win11:

• no error for opening .eml files
• no error for starting kleopatra while running (also not started twice anymore)

No it is not related to T4030 because that has not yet been implemented. I am just upload a beta479 which should fix problem as wel as other similar problems.

this also happens, when kleopatra is started while already running. kleopatra is started twice then.

maybe related: T4030: GpgEX: Use process calls instead of UIServer protocol

Indeed. We would need to add different entries to the context menu for each installation. Given that GpgEX needs to be replaced anyway and we will drop the need for a UI server socket (which is anyway only a trigger and no full communication).

Thanks for your work. I applied it to Gpgex.

Will do. Thank you very much.

Edit: The text below was wrong. The error given below only occurs when the combined path+filenmae is to long on windows.
An emoticon in a file below the folder to be encrypted does not hinder encryption via GpgEX.

Not sure yes If I rather fix this or do: T6331

Note to self after spending some time searching again for the documentation I saw previously about this: https://learn.microsoft.com/en-us/windows/win32/shell/context-menu-handlers#suppressing-verbs-and-controlling-visibility

Fixed in gpgex 1.0.8

Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.

Okay.

Alternative patch for Kleopatra:

diff --git a/src/uiserver/uiserver.cpp b/src/uiserver/uiserver.cpp
index d9746f0b..ab4d2ca7 100644
--- a/src/uiserver/uiserver.cpp
+++ b/src/uiserver/uiserver.cpp
@@ -23,6 +23,8 @@
 #include "kleopatra_debug.h"
 #include <KLocalizedString>

Not from understanding. libkleo adds high-level functionality that's useful for KDE applications, but out-of-scope for gpgme and its C++/Qt wrappers gpgme++ and qgpgme. I would use GpgME::dirInfo() directly in Kleopatra. It would make sense to add an overload of GpgME::dirInfo() that takes an enum, so that one does not have to use the low-level string names in Kleopatra. The downside is that a string-based interface can be extended easily. OTOH, deprecating values of a string-based interface is hard and after removing it the compiler won't complain.

We want to deprecate the whole UI-Server thing and thus I considered it better to provide the generic socket dir instead of adding support in libkleo for the uiserver socket. For the time being, doing this in Kleopatra sounds better to me. From my understanding. libkleo shall be an interface to gpgme++, right?

gpgme_get_dirinfo does already have support for "uiserver-socket" since about 7 years. I don't think a separate "socketdir" which requires a brand new gpgme makes much sense.

For Kleopatra this patch

It will be useful to have support in libkleo:

Thanks a lot.

Thanks Andre,

We have released 3.1.12 which updated all the GUI libraries Kleopatra uses and I got some feedback in related issues like T4689 that this might have helped.

I think this might be the issue with High DPI support problems. T4819 which is not yet released.

I see no reason to not allow decryption of an entire folder recursively. The user knows what they are doing by right-clicking a folder instead of a file. You can show a progress dialog with a cancel button.

Right. GpgEX is in serious need of polishing. I'm not sure if I'm in favor of processing all files recursively. But then the decrypt option should not even be shown.

3.1.11

Please let us know which version of Gpg4win you are using.

This should be normal priority as we continue to receive bug reports about UIServer and the usage in GpgEX of the UIServer protocol keeps us from removing it in Kleopatra.

I'll try to reproduce it.

We did not have more reports about this so I'm resolving it here.

fixed with rev. 4fbbd134b865b1203b1914eb1623fa65aab8cb75

Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).

Sorry for the delay, been a busy busy couple of weeks..

Setting this to resolved until we get reports to the contrary.

As GpgEX only queries a UI Server (GPA or Kleopatra) this is a Kleopatra or GPA problem.
With Gpg4win-3.0 Kleopatra got the option "Encrypt with password" in the file encryption dialog, which does symmetric encryption. GPA does not offer this but as Kleopatra is our main UI for GpgEX I think this feature request is done.

The only way I can think of that this fails if that there are some old files from a gpg4win installation that was not cleanly removed lying around and failing to start.

Since there was no action for half a year, I think this task can be closed.

With the Release of Gpg4win 3.0.1 this error doesn't appear anymore for me while testing.

Multiple bugs fixed here:

Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.

Hi,
I have tried this on Windows 10 (1511,1703,1709&RS4TP)
Gpg4win Version 3.0.0
Regards

Hi,
I was using Windows 7 Professional.
The last version that worked was gpg4win 2.3.4 (I didn't try any beta or rc), and encryption/decryption works fine for single files.

Hi, thanks for the report.

I have also experience the same bug and reported it on:
https://bugs.kde.org/show_bug.cgi?id=385390

Since this is a bug that is related to two different parts of the gpg4win package, this bug now only cares about the GpgOL Issue, that GpgOL crashes and cant decrypt messages from the sent folder that are encrypted with S/MIME. All File Based Issues are belonging to Kleopatra are documentet in the KDE Phabricator (https://phabricator.kde.org/T7310).

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

2. Files that are Signed and Encrypted to a S/MIME Certificate is broken. When you select a file and encrypt and sign it to a recipient, only a detached signature will be created and the Encrpyted file is missing. (Very similar to Issue 1, but file based).

https://phabricator.kde.org/D8368

So far we could recreate the following issues:

There are more Logfiles: