auto15963931 at hushmail.com
Sat Apr 7 17:31:57 CEST 2012
On 4/4/2012 9:50 PM, Hauke Laging wrote:
> This does not happen here (Linux, though).
Hauke, hello. I expect when I get to the bottom of it all, I will find
the fault is caused not by Windows but by my error or need for an
adjustment of some kind. I was hoping that my description would trigger
someone's idea about a similar experience so that they could provide a
pointer to jump start my fixing the issue. Anyway, I have made some
> However, much of the time I find that using this
> procedure does not cause the pinentry dialogue to move from one key
> to another but instead causes the dialogue window to close after
> either the first or second clicking on the cancel button instead of
> continuing on down through the complete list of keys I have
> available. It just fails to decrypt. This failure occurs mostly
> when I first try to use the procedure, but then it starts working
> properly after a few tries even though I do exactly the same steps
> each time. Why does it fail initially? Is this a known issue?
This part of the problem still exists. Individually trying to decrypt a
file encrypted with throw-keyids will fail, often but not always, to try
all the keys before aborting the effort. I can prevent the problem by
using "--try-all-secrets"; but, so far as I can see, this problem arises
only during individual file decryption and not during batch decryption
procedures. At least, this has been my experience up to now.
It is a puzzling phenomenon and not apparent to me what is behind it. It
almost seems like a memory thing or caching issue, but I'm not sure, yet.
> I have noticed a number of instances of failures during batch
> decryption too, even though the pinentry dialogue does not arise of
> course. These failures result in the "--status-file" indicating
> that the decryption failed although in fact I can find the
> decrypted message present.
This part I have solved. My batch routine was overwriting the good
output after the routine looped through the files again. I have changed
it now to circumvent the occurences and I get the correct results.
More information about the Gnupg-users