1 patch and 1 thought about Win32 port (keyring related bugs)
eutropos at hotmail.com
Mon Mar 14 10:22:27 CET 2005
I found a little time to debug in the week-end, and discovered the
This is the bug that prevented *ALL* keyring related operations on MSVC 6
compiled copy of GnuPG 1.4.0 (MSVC gives me something more than MinGW:
fastest code generation, slight better optimization performances, static
linking - which improves speed - and delay loading of WSOCK32/WS2_32...).
In fd_cache_strcmp (const char *a, const char *b):
DOSISH comparison gives wrong result (with MSVC only?). Try replacing
return *(const unsigned *)a - *(const unsigned *)b;
with this (since *a and *b already have omogeneous type, BUT FUNCTION MUST
RETURN AN INT!!!):
return (const int) *a - *b;
When a pubkey trust level has been changed, on the next execution GPG
complains that it can't rename pubring.gpg to pubring.bak.
Again there is an open HANDLE object for file pubring.gpg that prevents
renaming: but reason isn't BUG #1... Neither the reason is a pubring.tmp
file laying around (why is it still there???)
The problem could be a wrong design of FD cache system.
In fact, when the pubring.gpg file is opened for the first time by
direct_open, it isn't cached (since caching occurs on closing time only),
nor it's marked as directfp, I suppose... so, it isn't invalidated nor
closed by renaming function, since gpg knows nothing about it.
Simply make direct_open add a cache slot seemed to resolve the problem, but
has a *BIG* side effect - it can alter file pointer position of in-use open
file handles, wasting data I/O (data are corrupted during encryption, for
Perhaps someone should put an iobuf_close() somewhere (I tried it in
keydb_search, with bad results!)...
I have no time to debug anymore, so I hope this will help in some way.
Blocca le pop-up pubblicitarie con MSN Toolbar! http://toolbar.msn.it/
More information about the Gnupg-devel