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
R. B. Riddick
arne_woerner at yahoo.com
Sun Apr 1 20:20:09 UTC 2007
The following reply was made to PR bin/111101; it has been noted by GNATS.
From: "R. B. Riddick" <arne_woerner at yahoo.com>
To: Kris Kennaway <kris at obsecurity.org>
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 13:11:04 -0700 (PDT)
--- Kris Kennaway <kris at obsecurity.org> wrote:
> > 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.
Hmm... I was talking of the second lockf process, that does not create the
file, but that holds an exclusive lock on an unlinked file, which is completely
> > 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.
Water on my mills... There u have the contradiction...
> If you would like to submit a manpage change to expand upon the
> problems that can occur when not using -k, please go ahead.
Hmm... As long as u say, that I dont understand the use of lockf(1), I will not
say/request so much about it...
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
More information about the freebsd-bugs