Date: Mon, 5 May 1997 17:50:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: current@FreeBSD.ORG Subject: Re: Bug: is it the kernel or the man page? Message-ID: <199705060050.RAA17319@phaeton.artisoft.com> In-Reply-To: <19970506004851.HS60595@uriah.heep.sax.de> from "J Wunsch" at May 6, 97 00:48:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > The man page does not indicate that the advisory record locks on a
---------******------
> > file are lost on the first close, even if you have multiple fd's
> > for the same file.
>
> Not all advisory locks are lost, supposedly only those obtained by
> fcntl(). This is mentioned in great detail in the fcntl man page.
But not on the close man page. And the close system call is the actor,
in this particular case, so it should be documented there.
PS: I specifically stated "record".
PPS: The "in great detail" glowingly shouts the merits of flock(2) over
fcntl(2), while omitting the fact that that it is whole file rather than
the more useful record size locks, and the example explicitly violates
the layering protocol for access to files via subroutine, which is to
say, if file access is encpasulated, you wouldn't be locking it at the
top level anyway. The fcntl(2) man page should be corrected, since
while editorializing is annoying, it is tolerable only if it is correct.
PPPS: The F_POSIX should be F_LOCKF; the flag is used to indicate the
system call entry it came in on, not the semantic tagging.
PPPPS: There should be an F_NONPOSIX to again seperate the name space
so the flag could be set to avoid the behaviour; otherwise you can't
do NFS lockd descriptor coelescing properly. The F_FLOCK flag should
be used to discriminate the file locking name space (instead of the
stupid proc/fp method to cheesily seperate the name spaces). The
user could then use F_NONPOSIX to subvert the close behaviour. Say
if the user was the zealot who wrote the fcntl(2) man page, or maybe
the more reasonable NFS lockd.
PPPPPS: The lock coelesce in the lf_setlock case should be delayed to
allow NFS to provisionally assert the lock locally, and then back
it out if it fails on the NFS server. Otherwise, there's no way
to idempotently protect local vs. remote processes from leaving holes
in the lock graph if one or the other fails.
I'll fix the lock code. You fix the man page.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705060050.RAA17319>