Preventing temporary files?
dougb at dougbarton.net
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