From owner-freebsd-bugs@FreeBSD.ORG Sun Apr 1 20:10:13 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36D3216A402 for ; Sun, 1 Apr 2007 20:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id D5AB113C45B for ; Sun, 1 Apr 2007 20:10:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l31KACCv079260 for ; Sun, 1 Apr 2007 20:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l31KACQm079256; Sun, 1 Apr 2007 20:10:12 GMT (envelope-from gnats) Date: Sun, 1 Apr 2007 20:10:12 GMT Message-Id: <200704012010.l31KACQm079256@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Kris Kennaway Cc: 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 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kris Kennaway List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2007 20:10:13 -0000 The following reply was made to PR bin/111101; it has been noted by GNATS. From: Kris Kennaway To: "R. B. Riddick" Cc: Kris Kennaway , freebsd-gnats-submit@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 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