Let's schedule that for 2.6

Possibly, it may consider the case where errno==0 when failure.

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

Fix merged to release/23.04 branch.

And thanks gniibe! I have tested 2.4.1 several times in this month (including existing and new keys), the warning was never shown again.

Hi zhangguangzhi, I think that it's version-specific problem.
I traced the chain and this warning message was added in release 2.3.3 T5565.
The problem should be able to reproduce between 2.3.3 and 2.4.0.

Hi，i try to reproduce the problem, my platform is linux and gnupg2-2.2.32-3, but i can't find “gpg: warning: lower 3 bits of the secret key are not cleared". Excuse me, is this a platform-specific or version-specific problem, or is it my operation wrong.

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

So the reason this fails is the same as it was back when T3547 was fixed. MoveFile does not work across directories, and even MoveFileEx that supports this for files does not support this for directories.

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.

Since it's ABI change, I created a branch: https://dev.gnupg.org/source/libassuan/history/gniibe%252Ft6487/

So if I have \MyDirectory\pubring.pgp and MyDirectory\secring.pgp files, how do I use the --homedir option to access those?

For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.

I conclude that adding two public functions for pipe connection of client will be useful (and solve the pid_t issue, by successfully hiding those use cases).

I pushed the change which keeps old status report behavior to master.
Let me test the change.

looks simpler to me.

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.