Preventing temporary files?

Doug Barton dougb at
Fri Mar 11 03:16:15 CET 2005

Werner Koch wrote:
> On Wed, 9 Mar 2005 21:14:40 -0700, Joseph Bruni said:
>>themselves such as that provided by flock() for the BSD unixes and
>>lockf() for the SVR4 unixes? Was this for portability reasons?
> Yes, this is a portability issue.  A lock file is the only way to take
> a lock in a portable way independed of the file system.  In general it
> also work with remotely mounted file systems accessed by different
> types of OSes.

In my past life as a systems programmer in a Unix environment I did a lot of 
research on this for a project I had that needed to run across a variety of 
systems, including NFS mounts where the status of the system locking was 
unknown. It turned out that the most effective way to handle this was 
actually to create a lock directory rather than a lock file. The main reason 
this was a better solution is that (as I understand it) directory creation 
is specified by POSIX to be an atomic operation, and therefore isn't 
susceptible to race or locking issues in the same way that file creation is. 
(Note, nothing was put in the directories, their successful creation was the 
threshold operation for locking.)

I'm not suggesting here that gnupg change anything, I just wanted to point 
this issue out in case at some point down the road a solution is necessary 
for weird issues that file based locking doesn't solve.

Hope this helps,


     If you're never wrong, you're not trying hard enough

More information about the Gnupg-users mailing list