GnuPG 1.2.6 binary for win32?

Werner Koch wk at
Mon Sep 6 10:19:46 CEST 2004

On Sun, 5 Sep 2004 19:09:52 +0200, Andreas John said:

> Well, this is what I found out about Compatibility mode: Any process
> can open the file any number of times with this mode.  It fails if
> the file's opened in any other sharing mode.

OKay, compatibility mode might not be the correct term. Anyway, files
are opened in the default mode and thus only the first open will
succeed and all other opens are going to fail - even from the same
process. This is the reason whey we had to tweak the file opening
from time to time.  IIRC, 1.3.x currently has a problem with this.

> Another thing: I just had a quick look into the GPG1.2.6 dotlock.c (to get a better feel for the problem) and I think I've found a small memleak for win32:
> The destroy_dotlock()-function does nothing for DOSISH_SYSTEM, whereas the create_dotlock()-function doesn't do too much, but at least mallocs the returned DOTLOCK as well as the lockname-member, so the mfree gets never called.

Thanks.  I fix it.

> I'm not sure, but it seems not too hairy to write some win32-code to do the required locking with dropping of the verbose dotlock-file-management (eg. using _get_osfhandle() and LockFile()?).

We don't need any locking unless we want to improve on the performance

> Anyway, I believe the bigger problem is the different rename-semantics of windows and unix.

We know that there is a problem but did not look closer at it.

> The SHARE_DELETE-Flag might help, but is not available in win9x.

So we can't use it.



Please take care not use use overlong lines, your lines are far too
long; 72 is a good limit.

More information about the Gnupg-devel mailing list