1 patch and 1 thought about Win32 port (keyring related bugs)

[Eutropos Eutropou]

I found a little time to debug in the week-end, and discovered the 
following:

BUG #1
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;


BUG #2
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 
example).
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/