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: Arne Woerner <arne_woerner at yahoo.com>
Cc: 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 15:53:08 -0400

 On Sun, Apr 01, 2007 at 06:41:43PM +0000, Arne Woerner wrote:
 
 > >Description:
 > I use lockf in order to coordinate the access to my TV frame grabbers (/dev/cxm?).
 > 
 > When another recording starts (process B) it can happen that a previous recording (process A) still needs some seconds, I end up with an unlink-ed lock file.
 > 
 > I would expect the following order:
 > 
 > 1. process A: holds file LCK
 > 2. process B: blocks on file LCK
 > 3. process A: unlinks file LCK
 > 4. process A: releases lock on file LCK
 > 5. process B: locks the already opened but unlinked file LCK
 > 6. process B: checks, if file LCK still exists
 > 7. process B: creates file LCK
 > 8. process B: locks file LCK
 > 
 > As a workaround I use lockf with option "-k", which should solve that problem...
 > 
 > 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.
 
 It appears that lockf is working as designed, and also as explicitly
 documented.  It looks like no action can be taken here.
 
 Kris