From 6f72aa821407e47ad3963e72e139f2ca2c69d9dd Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Tue, 14 May 2019 19:05:58 +0200 Subject: kbx: Fix deadlock in gpgsm on Windows due to a sharing violation. * kbx/keybox-init.c (keybox_lock) [W32]: Use _keybox_close_file instead of fclose so that a close is done if the file is opened by another handle. * kbx/keybox-search.c (keybox_search): Remember the last offset and use that in NEXT search mode if we had to re-open the file. -- GnuPG-bug-id: 4505 Signed-off-by: Werner Koch --- kbx/keybox-init.c | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) (limited to 'kbx/keybox-init.c') diff --git a/kbx/keybox-init.c b/kbx/keybox-init.c index 6a83f7162..6d656f2f8 100644 --- a/kbx/keybox-init.c +++ b/kbx/keybox-init.c @@ -289,18 +289,14 @@ keybox_lock (KEYBOX_HANDLE hd, int yes) if (!kb->is_locked) { #ifdef HAVE_W32_SYSTEM - /* Under Windows we need to close the file before we try - * to lock it. This is because another process might have - * taken the lock and is using keybox_file_rename to - * rename the base file. How if our dotlock_take below is - * waiting for the lock but we have the base file still - * open, keybox_file_rename will never succeed as we are - * in a deadlock. */ - if (hd->fp) - { - fclose (hd->fp); - hd->fp = NULL; - } + /* Under Windows we need to close the file before we try + * to lock it. This is because another process might have + * taken the lock and is using keybox_file_rename to + * rename the base file. Now if our dotlock_take below is + * waiting for the lock but we have the base file still + * open, keybox_file_rename will never succeed as we are + * in a deadlock. */ + _keybox_close_file (hd); #endif /*HAVE_W32_SYSTEM*/ if (dotlock_take (kb->lockhd, -1)) { -- cgit v1.2.3