We have seen this problem in the QA this week and could identify that this was a ERROR_FILE_INVALID (ec=1006,"The volume for a file has been externally altered so that the opened file is no longer valid"). We also noticed disk errors in the event logger but did not recorded them. The USB stick was not unplugged but merely used with VirtualBox.

High priority because I a fear that we will soon start to receive support questions related to this.

I guess kleo does a directory listing and then sorts hat listing the view Using the name by default but you can change this. Passing this list down to gpgtar is likely the original list as received from the OS. I also guess it will be easy to sort this but I'll give it a low priority.

Well, it Just Works(tm). You should make sure that a /run/user/NNNN direcory exists so GnuPG is able to create its subdir for the socket files.

To align the default expiration time with the BSI approval and other related software we change this now to 3 years.

Works in kleopatra; tested with gpg4win-4.2.0-beta339.

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

See also commit rG6fcc263c18 from 2020 where I switched to D-lines.

Let's schedule that for 2.6

Hmm, gcc used to figure out that attr is initialized by npth_mutexattr_init. One of these gcc warning regressions?

Due to back porting another change the fix for 2.2 is now also needed in 2.4.

FWIW: I have not done any tests but the comment below is about the case I suspected to be the cuase for your problem:

See rG0988e49c45 which implements time and group but not yet the split thing because we are not shure that is good idea to have this w/o any implementation support.

The fix actually does the same as my suggested workaround.

There is an easy workaround: Append an exclamation mark to the adsk key. This way gpg will only search for this subkey.
An example with my test keys:

secring.gpg is only used by unsupported legacy versions of GnuPG. Since 2.1 it is not anymore used.

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

Hmm, for the latter this:

Kleopatra test case (similar to gpg):