bin/111101: /usr/bin/lockf: when lockf blocks due to another lockf and no -k is specified and the other lockf ends, the file is away

[Kris Kennaway]

The following reply was made to PR bin/111101; it has been noted by GNATS.

From: Kris Kennaway <kris at obsecurity.org>
To: "R. B. Riddick" <arne_woerner at yahoo.com>
Cc: Kris Kennaway <kris at obsecurity.org>, freebsd-gnats-submit at FreeBSD.org
Subject: Re: bin/111101: /usr/bin/lockf: when lockf blocks due to another lockf and no -k is specified and the other lockf ends, the file is away
Date: Sun, 1 Apr 2007 16:04:28 -0400

 On Sun, Apr 01, 2007 at 12:59:53PM -0700, R. B. Riddick wrote:
 > --- Kris Kennaway <kris at obsecurity.org> wrote:
 > > On Sun, Apr 01, 2007 at 06:41:43PM +0000, Arne Woerner wrote:
 > > > Furthermore I would like to recommend, to make the "-k" behaviour the
 > > > default behaviour, so that we will not remove data files, that were co-used
 > > > as lock files...
 > > 
 > > We cannot do that, not using -k is required in some situations, so
 > > those scripts will break.
 > >
 > OK - recommendation withdrawn...
 > 
 > > It appears that lockf is working as designed, and also as explicitly
 > > documented.  It looks like no action can be taken here.
 > > 
 > Explicitly? Documented? Since I have not found that documentation, can u help
 > me a little bit by showing it?
 > 
 > In the mean time I show a piece of my documentation (man page lockf(1)):
 > "DESCRIPTION
 >      The lockf utility acquires an exclusive lock on a file, creating it if
 >      necessary, and removing the file on exit unless explicitly told not to.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This is even underlined.
 
 >      While holding the lock, it executes a command with optional arguments.
 >      After the command completes, lockf releases the lock, and removes the
 >      file unless the -k option is specified.  BSD-style locking is used, as
 >      described in flock(2); the mere existence of the file is not considered
 >      to constitute a lock."
 > I repeat: "CREATING IT IF NECESSARY"
 > 
 > If think, the explicit documentation says, that the file is created (although
 > this "if necessary" is somewhat weaselish, so that the man page should be
 > changed, too; it should say: "creating it if it does not exist").
 
 But that is what "if necessary" means.
 
 > Currently without the "-k" option given only the first conflict is solved
 > properly, while the next is not, which is surely not what we want, and which is
 > surely nowhere documented.
 
 If you would like to submit a manpage change to expand upon the
 problems that can occur when not using -k, please go ahead.
 
 Kris