GnuPG 1.2.6 binary for win32?

[Andreas John]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

> We have nio locking in Windows at all.  IIRC, all files are opened in
> "compatibility" mode, meaning that only one process may have it open.
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.
And: Because the default is "compatibility" mode, it means that by default most applications can't ensure the integrity of their data.  Instead of your data being secure by default, you need to take special actions to guarantee that nobody else messes with the data.
(http://blogs.msdn.com/larryosterman/archive/2004/05/13/131263.aspx)


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.


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()?).
Is there any work done for GPG 1.4? Or won't proper handling for win32 be there even with GPG 2.0?
In case this was discussed already, please give me note.
Also, I'd be willing to do spend some time coding myself if required to get it done. So indeed I'm interrested in discussing this topic.

Anyway, I believe the bigger problem is the different rename-semantics of windows and unix.
The SHARE_DELETE-Flag might help, but is not available in win9x.
So if it should become correctly working in all blends of windows there must be some other mechanism implemented to do the renaming (eg., also lock files for read-access, and then copy whole data into the locked file instead of rename).
Hehe, okay, I really doubt you'll consider this at a stage this late :))

But has anybody a better solution? Maybe some mechanism to let the rename be done by the last instance of gpg running? Also a complex task for an unloved system...



Bye!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32) - GPGrelay v0.954

iD8DBQFBO0hrnTiKrQObWqkRApngAJ9GVCSUE2qy3rm+CTHN8N2Eyd7M7gCfdWab
trFq2QwTLK0HoV9uGtvg7vs=
=FI1Z
-----END PGP SIGNATURE-----