lockf and the SVID, (Was "Re: Wanted: lockf system call source")

[Dave Lennert]

Thanks for all your explanations.  Much confusion arose because, in my
original posting, I said fcntl() once when I meant lockf().  Also my
question was not well worded in general.  I apologize.

Some caught the thrust of my question, which was that lockf() (as
implemented in SysV on top of fcntl()) requires write permission to the
file descriptor in order to do locking.  This is not strictly compatible
with the /usr/group specification of lockf() which merely states that
it needs "an open file descriptor".

Arguments about the appropriateness of the lockf() interface aside, my
point was that the SysV lockf() does not correctly implement the
specification from /usr/group, and hence customers may have problems
importing programs using lockf() from other systems.

For example, if my application attempts to do "read locking" via lockf()
on a file descriptor that it only has read access to, it will fail on
Sys V.  (Note that lockf() doesn't make the distinction between read and
write locking.)

Again, my point is not whether SysV lockf() is better but whether it is
compatible.  I meant to solicit input from the community as to which
they felt was more important ("better" or "compatible"); I'm especially
interested in whether anyone out there has an existing application which 
relies on lockf() working on a file descriptor without read permission.

Thanks to Daniel Steinberg of Sun Microsystems (sun!dss) whose private
mail clarified these issues for me.

Thanks again.

    Dave Lennert                ucbvax!hpda!davel               [UUCP]
    Hewlett-Packard - 47UX      ihnp4!hplabs!hpda!davel         [UUCP]
    19447 Pruneridge Ave.       hpda!davel at Berkeley.edu         [ARPA]
    Cupertino, CA  95014        (408) 447-6325                  [AT&T]