When initially started from the command line (either directly or secondarily via
gpg --sign ..., the gpg-agent creates a lock on the current directory and
doesn't release it until gpg-agent exits.

This makes the directory un-deleteable until the process is killed. If it needs
a lock, it should lock an essentially unremovable directory (such as
%USERPROFILE%, if it needs to be user-owned).

This is a especially a problem when signing files which are in a temporary
directory (such as packages prepped for distribution) which would then be
deleted (with the enclosing directory).

I've noticed this is a problem ever since the 2.0 release using a graphical user
agent.

Thanks for taking the time to look into the problem.

There is no lock on a directory. However, several lock files are created in the
GNUPGHOME directory. Sure, you can't delete them as long as the processes
holding them are alive.

Can you please give more detailed information on your problem? For example the
name of the lock files and which processes are holding them? How can we
replicate the problem.

No, it's not the config files that are a problem. And maybe I'm using
imprecise terminology. But, the gpg-agent process maintains an open
handle on the current working directory in which the process is started,
until it is killed. Here's an example:

c:\#temp\gpg-agent-test>handle c:\#temp\gpg-agent-test
Handle v3.41
Copyright (C) 1997-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

cmd.exe            pid: 11248    98: C:\#temp\gpg-agent-test

c:\#temp\gpg-agent-test>"C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe"
--daemon
set GPG_AGENT_INFO=C:\Users\Roy\.gnupg\S.gpg-agent;13644;1
gpg-agent[13644]: gpg-agent (GnuPG) 2.0.30 started
gpg-agent[13644]: DBG: returning notify handle 00000230

c:\>rem:: in another CMD window

c:\>handle c:\#temp\gpg-agent-test

Handle v3.41
Copyright (C) 1997-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

cmd.exe            pid: 11248    98: C:\#temp\gpg-agent-test
gpg-agent.exe      pid: 13644    7C: C:\#temp\gpg-agent-test

Initially, a directory handle is held only by the CMD process with current
working directory (CWD) equal to the directory... normal circumstances. As
shown, when gpg-agent is executed as a daemon from that directory, it
adds an additional open handle (or "lock" in my prior terminology). When
using gpg ..., the agent puts a hold on the CWD, and that's the problem
when signing a directory or within a directory which is subsequently
deleted. The continuing open handle blocks the deletion... a real problem
when signing a directory of files which are only around to package for
distribution.

A workaround is to independently start the agent from another, more
permanent, directory in daemon-mode. Then it holds a handle to just that
directory and you can use it to sign at any point in the path without
further open handle issues. So, it's annoying and causes weird build
errors, but it's not insurmountable. However, the errors it causes are
remote from it's use, are not obviously related, and occur only for the
first directory it opens, so folks are going to have puzzling "undeletable
directory" errors.

To show the process handles, I'm using the handle tool from
sysinternals.com. You'll need to have admin privs to execute it in
Windows8+.

Thanks for your very rapid response.

On Mon, Sep 5, 2016 at 9:44 AM, Werner Koch via BTS <gnupg@bugs.g10code.com>
wrote:

Werner Koch <wk@gnupg.org> added the comment:

There is no lock on a directory. However, several lock files are created
in the
GNUPGHOME directory. Sure, you can't delete them as long as the processes
holding them are alive.

Can you please give more detailed information on your problem? For
example the
name of the lock files and which processes are holding them? How can we
replicate the problem.

---

GnuPG's BTS <gnupg@bugs.g10code.com>
<T2670>

---