Date: Sun, 1 Apr 2007 20:10:12 GMT From: Kris Kennaway <kris@obsecurity.org> To: freebsd-bugs@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 Message-ID: <200704012010.l31KACQm079256@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/111101; it has been noted by GNATS. From: Kris Kennaway <kris@obsecurity.org> To: "R. B. Riddick" <arne_woerner@yahoo.com> Cc: Kris Kennaway <kris@obsecurity.org>, 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 <kris@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704012010.l31KACQm079256>